Thursday, August 31st, 2006

JavaScript Persistent Object Notation (JSPON)

Category: JavaScript

Kris Zyp has written up a RFC for JavaScript Persistent Object Notation (JSPON). The idea is to standardize a method for the identification of objects for efficient transfer and persistence of objects within large object graphs.

JavaScript Persistent Object Notation (JSPON) is a data-interchange format with the goal of simply being a defined usage of JavaScript Object Notation (JSON) to facilitate JavaScript objects that are intended to persist by defining a scheme to provide the necessary semantics needed for efficient and meaningful persistent objects. JSPON is pure JSON and maintains the same simplicity of JSON, and establishes a format for serializing and referring to objects to enable the persistence of JavaScript objects and object graphs by defining a set of fields for identification, deferred value loading, decentralized object creation, and primitive value, function and array object augmentation.

JSON provides simple straightforward mechanism for serialization of objects that can efficiently and easily be read by humans and machines. JSON can be adequate for the persistence of simple small objects. However applications that have large complex object graphs and sets of data generally require the exchange of smaller subsets of the data/object graph to be transferred and persisted at a time rather than requiring an entire object graph to be treated as whole, as well as allow objects to be referred from multiple fiels. Such operations on subsets of data entail identifying objects within a graph and allowing for transfers of subsections of object graphs (and not just end point subsets). JSPON provides the common language so that objects can be passed with proper identification and reference information. This also allows objects to be referred to more than once (not possible within a normal JSON object graph). Standard JSPON simply defines several fields that can be added to JSON object to assist in data description.

Posted by Dion Almaer at 9:50 am

3.6 rating from 27 votes


Comments feed TrackBack URI

My apologies. It looks like some of the formatting got stripped off of my previous comment.

Comment by Terry Laurenzo — August 31, 2006

I took a look at your blog, very interesting to see you wresting with some of the same things I have. The persistence issue is definitely not trivial. Anyway, I certainly do have an implementation behind this RFC. (I was hoping that the RFC didn’t look too implementation driven, so I am glad it you didn’t notice). In my approach the server has the master object graph. The client/browser then makes request for different objects from the server. As they are delivered from the server they include identification per the spec. Objects can be referenced that have been downloaded yet, and when the client encounters these objects, it can request them from the server.My approach is a little different because I am not attempting adhoc serialization of any JavaScript object, but rather all persistable objects are instances of certain constructor. When the server delivers object graph information from the server, the client creates JavaScript objects that are instances of the PersistentObject. It actually creates objects that are like Java beans, with getters and setters. That way code can access fields through getters and the getters automatically handle retrieving data from the server when additional object graph data is necessary. If a user wishes to add an peristent object to the persisted object graph they must instantiate from the PersistentObject constructor. It then gives itself a temporary client side id, and once it is persisted to the server, the server gives it a permanent unique id for the master object graph. This deals with id collision problem. This is why the JSPON spec provides an id field and a clientid field. Newly created objects from a client should not attempt to assign their own id in the context of the master database, they can only assign themselves a temporary id within their own context until the server assigns a permanent one.
Anyway, my project is still under development, but just to see a little results, you can catch a glimpse of it in action when you visit You will notice there is basically no HTML for the page, rather JavaScript requests a root object from the object graph, and then builds the web page on the client side using object graph and requests are made from the server as needed for additional parts of the graph. Even a lot of the code is delivered in the object graph. Therefore the entire page rendering process takes place completely on the browser. I think this is really an evolutionary approach, as you end providing a means for a true client centric model-view-controller programming model. The logic processing of the application and displaying the web page and interacting with user is all centered on the browser, no awkward remote links in the MVC as occurs in almost all web applications, and the remote connection is just used for providing object graph information for the framework. The server can then could do very effective look ahead caching to accelerate the process.
This is also really cool because it really lessens the load on the server, the server is never really doing any complicated page rendering, just delivering JSON/JSPON objects. The browser does all the work. And it is surprisely fast. A lot of the effective parsing is done by innerHTML calls which are extremely fast.

Comment by Kris Zyp — August 31, 2006

Interesting Finds: August 31, 2006

Trackback by Jason Haley — August 31, 2006

Can we prepare dynamic graph at the client side which will show the speed of the charactor entered by the user…..

Comment by Kirankumar — October 18, 2006

Leave a comment

You must be logged in to post a comment.