jabsorb 1.2.2 Release
January 22nd, 2008
Arthur Blake recently released jabsorb 1.2.2:
jabsorb is a simple and lightweight (yet quite powerful) Ajax/Web 2.0 framework that allows you to call methods in a Java web application from JavaScript code running in a web browser as if they were local objects residing directly in the browser.
The most important feature in the jabsorb 1.2.x release line is an extension to the JSON-RPC protocol that allows passing of data structures with circular and duplicate references.
With jabsorb 1.2.2 the json-rpc-client project has been combined with jabsorb to include an additional Java client to the jabsorb server. Special thanks to Sasha Ovanskin for this immensely useful contribution.
Additionally, the jabsorb team has recently rolled out a whole new web site, wiki and infrastructure at http://jabsorb.org
XMLHttpRequest.responseJSON
January 14th, 2008
With the recent W3C proposal for cross site XMLHttpRequest capabilities through Access Control headers, JSONRequest may not be the only standards based client side approach for creating mashups that utililize cross site data. One of the advantages of JSONRequest is that it can safely and efficiently evaluate JSON data (safer and more efficiently than an “eval” call). However, the new cross-site enabled XMLHttpRequest could provide this capability as well with the intuitive addition of a responseJSON property. Currenty the XMLHttpRequest object has responseXML property that returns the resource parsed as XML (when the content type is text/xml or application/xml). However, since JSON is becoming the data format of choice for XMLHttpRequest, it would seem logical to provide a property that returns the resource as parsed JSON (when the content type is application/json).
With the potential new cross-site capabilities of XHR, I have been thinking about how I could port CrossSafe to the XHR API. Since CrossSafe operates by passing JavaScript objects (parse JSON data) across iframes, it would create a large inefficiency to reserialize the JavaScript objects back to JSON in order to fulfill the standard responseText property of XHR (since it would probably just be re-parsed back to JavaScript objects again). It would be much more efficient to expose the parsed JSON data through a responseJSON property. I would love to see this property added to the XMLHttpRequest API so the CrossSafe/Subspace technique could be accessed efficiently through the widely known and understood XHR API.
New JSON Parsers
January 7th, 2008
Several new or updated JSON parsers have been released recently:
- Version 1.1.0 of DOMJson of the JON Tools project has been released with the following new features:
- JSON Schema validation
- JSONPath support
- TinyJSON - A very lightweight C++ JSON parser.
- JSON parser - an extension of the JSON_checker code, that adds optional C-style comments, and extra character decoding capabilities.
A Standards Based Technique for Batching Ajax Requests
January 3rd, 2008
A little off the topic of JSON, but I recently wrote an article for Comet Daily that was a proposal for a standards based approach to comet communication. One of the key components of the proposal that made it go, was the mechanism for using standards to coherently subscribe and respond to multiple resources. By applying the message/http content type to HTTP messages, multiple HTTP messages can be wrapped up in single message using a standard MIME type. In the MIME type specification, the message/http is defined in the context of email messages as being a container for multiple email messages. However, it does not take too much imagination to infer that when this content type is used in the context of a HTTP messages, that the content would be a multipart message composed of multiple HTTP messages.
While there are certainly client/server frameworks out there that support Ajax batching, they all do so with their own internal protocol. Using the message/http content type opens the door for batched Ajax requests with an open protocol that would allow client libraries to send batched requests to various server side components. Perhaps at some point, I will try to create a client library that will modify the XmlHttpRequest object to support batched requests using this technique, and a Java filter that can understand and segregate the requests using this technique.
Update: Originally I suggested using multipart/digest as the content type, but I believe that message/http is more semantically correct.
Joining SitePen
January 2nd, 2008
I am pleased to announce that I am now officially a SitePen employee. Today is my first day with SitePen, and I am very excited to be surrounded (in a virtual sense) by such a brilliant group of people. I will be a Research and Development Associate under Alex Russell. SitePen is extremely forward thinking in evolving web technology and pursuing the Open Web, and therefore I will continue to have opportunities to work towards open formats and standards for JSON interchange and interoperability, as well as other new arenas of development. SitePen has a strong sense that what is good for the web is good for SitePen, and in doing some has made incredible contributions to the open source community in Dojo, Dojo Offline (and it’s influence on Google Gears), and more, and I am exciting to join with SitePen in the pursuit of a better web for everyone.
JSONP Header Transfer Proposal
December 24th, 2007
JSONP is a proposal for performing cross site JSON data interchange by using script tag insertion with a callback to deliver the data payload. JSONP can be used in place of XmlHttpRequest in cross site situations. However, when using XmlHttpRequest, there are situations where the JSON data in content body is not the only relevant information, but the response headers, as well other aspects of the HTTP request and response may also contain important information. I propose that JSONP can extended in a small and simple manner to accommodate the transfer of header information in suitably interoperable manner.
I propose when custom headers need to be included in the request, that headers simply be included as parameters. When servers that are responding to JSONP requests want to include response header information in the response, they may optionally respond with a second argument that contains header information in the form of an JSON object/map. The object should contain properties with the names corresponding to header names, and values corresponding to header values. The request format can remain the same:
http://myserver/requestJSON?callback=mycallback&Accept=application%2Fjson
And the response would look like:
mycallback({"name":"foo"},{"Content-Type":"application/json","Expires":"Mon, 24 Dec 2007 17:09:04 GMT"})
This addition to JSONP should generally not break existing JSONP clients, as normally only one parameters is used. This allows JSONP to emulate more semantically correct manners of transferring information that conceptually belongs in headers.
Usages could include transferring the “Last-Modified” header, so clients could determine the freshness of the data, sending If-Modified-Since header in requests and many more.
In addition to transferring request and response headers, I propose that additional HTTP information could also be transferred in pseudo headers. The following pseudo headers may be used:
- request
- httpMethod - Indicates the HTTP method used (GET, POST, PUT, DELETE, etc).
- httpContent - Indicates the body of the content of the HTTP request (such as the POST body)
- httpNoCache - With non-idempotent methods, you should generally include an additional parameter with a random unique value to ensure that the request is not cached.
- response
- httpStatusCode - Indicates the HTTP status code.
- httpStatusText - Indicates the HTTP status text.
A more sophisticated example request could be:
http://myserver/requestJSON?httpMethod=POST&httpNoCache=23n9zs92l&httpContent={"name":"bar"}&callback=call1
And the response could be:
call1([{"name":"foo"},{"name":"bar"}],{”httpStatusCode”:200,”httpStatusText”:”OK”,”Date”:”Mon, 24 Dec 2007 17:09:04 GMT”})
Of course, this enables a greater level of interaction, and therefore the prerequisite security warnings must be heeded. You can get yourself in a lot of trouble with XSS if you are not using proper explicit authentication schemes.
December 21st, 2007
Below is a presentation on JSON I gave a few months ago for some colleagues. The first three videos cover different emerging JSON extensions and standards, and the next three videos cover tools that I have built for working with these JSON extensions.
These three videos cover tools I have built for JSON. The primary tool that is discussed is Persevere (and Jsponic which has been renamed to Persevere server):
Non-Relational Web DB Interoperability
December 17th, 2007
Alex Russell recently wrote about the advantages of non-relational (dynamic object) databases for application development. The flexibility of using dynamic persisted objects that behave like dynamic OOP objects provides a great level of agility in progressive iterative development. Objects can automatically be persisted, virtually eliminating the overhead of developing around a database. I certainly am a proponent for this type of application development, it is exactly what my project Persevere is built for.
Alex also talked about a number of other offerings including SimpleDB and CouchDB that can provide database services through web/HTTP interaction. While of course, I think Persevere is further along and more powerful than these other systems (with full client and server automated orthogonal persistence, function storage, JSONP, JSONPath, JSON Schema support, and more), I think that even more important than trying persuade the superiority of one system, is to espouse the benefits of interoperability of these systems. It is highly unlikely that one web service DB is going to be a monopoly anytime soon. With the availability of multiple web services, sites will certainly want to take advantage of varied web services and mashups will quickly grow in popularity. The cost and difficulty of these mashups will hinge largely on what degree of interoperability exists between these web services.
When using databases that are particularly suited for persisting dynamic object/map style data, JSON is certainly an obvious choice for interoperability, simplicity, and adoption. In addition, we have one of the most widely adopted standards on the planet available to us in the REST HTTP vocabulary (GET, POST, PUT, and DELETE). These HTTP methods in combination with JSON can provide a very simple intuitive interface for many basic database operations. While SimpleDB uses REST HTTP methods, unfortunately it does not seem to be based on JSON. However, both Persevere and CouchDB indepedently came to use this JSON REST approach for database interaction, and conseqently have a very high level of interoperability opportunity.
The basic HTTP verbs provide a broadly accepted standard for basic database operations, but generally queries entail more power and sophistication than simple id based GET requests can provide. SimpleDB defines it’s own query language. CouchDb does not have a query language (as far as I can tell), but rather relies on server side JavaScript mapping functions. Persevere uses JSONPath for it’s query languages and also supports server side JavaScript mapping functions. JSONPath seems to be an emerging standard, and as mentioned in the last post, will probably even be included in Dojo in the future.
I believe it is important that these different web storage engines both continue to innovate and evolve, but also work hard to find opportunities to work together for interoperability as well.
dojox.jsonPath
November 29th, 2007
Dustin Machi of SitePen has been working on adding a JSONPath module to DojoX. He is using also utilizing this module for a dojox.data store that extensively uses JSONPath. Of course this is not available in the general Dojo release yet, but it is in the Dojo SVN/nightlies. It is great to hear that JSONPath is continuing to gain traction.
Comet Daily
November 26th, 2007
I pleased to announce I have recently joined the team of Comet Daily contributors. I will be writing articles and musings on a regular basis for this new site. I am exciting about this opportunity to participate in the discussion and dissemination of the advance of Comet technology alongside some brilliant people in this area. You can see my first article on Comet discussing Event and REST approaches to Comet. I will probably be focusing a lot on REST approaches to Comet with my blog posts.
« Previous Page — Next Page »