OpenAjax Concerns
January 31st, 2008
Ric Johnson posted some concerns about OpenAjax. Ric is the donor for multiple important domains like this one, and I certainly appreciate his efforts to further the open web, and believe that it does indeed behoove us to recognize the donors of sites like OpenAjax. Thanks, Ric!
Update:
I recently heard from Jon Ferraiolo of OpenAjax, and he working on getting the next revision of the web site finished, which will include a link to their domain donor, OpenDomain. Thanks Jon, for moving this forward.
Defining JSON Referencing Convention with JSON Schema
January 22nd, 2008
I have been involved in lengthy discussions on the best approach to JSON referencing. I have long wished for a single convention for JSON referencing, but the numerous approaches currently in use have frustrated my attempts at consensus. In some situations path-based referencing can be a very clean approach for intra-message referencing. On the otherhand, id-based referencing can be preferential, especially when objects already have unique identifiers and/or when referencing outside the local JSON message is necessary, but settling on a convention for referencing is difficult. With id-based referencing one of the sticky points is defining the identity property. I have long argued for always using “id” as the identity property, but others have felt that this may result in the id property may not necessarily be globally unique. Others use an identifier property in the root of objects that defines the identity property for the rest of the object. This allows for flexibility of defining alternate identity properties, but unfortunately mixes meta data right into the data payload.
Perhaps rather than requiring a single agreed upon identity property for interoperable JSON referencing, it may be more reasonable to allow JSON providers to define their own identity and referencing property with a JSON Schema. JSON Schema currently includes a “unique” attribute that is used to define a property as being unique. A JSON Schema can easily declare the identity property by defining a single unique property in the schema. Ids can also be declared as URLs with relative resolution that has the broadly powerful capabilities of not only intra-message referencing, but also cross-site referencing.
Agreeing upon a single referencing property (I have proposed “$ref”) is less problematic, the “$ref” is unlikely to clash with existing properties, and there is little chance for property reuse like with ids. Nonetheless, it would be possible to add a special attribute to JSON Schema to denote a referencing property. This attribute could also signal what forms of referencing to expect (path-based, id-based, or both). An example JSON Schema that defines referencing capabilities might look like:
PersonSchema=
{"type":
{"person_id":{"unique":"true","type":"string","format":"url"},
"name":{"type":"string"}},
"referenceProperty":"$ref",
"referencingForm":"both"}
While I still like the ease and efficiency of a single JSON referencing convention, the flexibility of defining the id and referencing properties with JSON Schema may be reasonable approach to the future of JSON referencing. What do you think?
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.
« Previous Page — Next Page »