W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: [Fwd: Offline data synchronization API]

From: Kris Zyp <kris@sitepen.com>
Date: Sat, 21 Jun 2008 10:09:44 -0600
Message-ID: <004d01c8d3b9$396af320$4200a8c0@kris>
To: "Maciej Stachowiak" <mjs@apple.com>, "Nikunj Mehta" <nikunj.mehta@oracle.com>
Cc: "Arthur Barstow" <art.barstow@nokia.com>, "WebApps WG" <public-webapps@w3.org>

>> Here's a paper that describes the use cases and requirements about
>> AtomDB. It does not include API details, although if you find this
>> interesting, we can proceed to that next.
>> I look forward to reading comments and getting feedback from the
>> community

I am very interested in this type of REST/CRUD offline auto-synchronization, 
we are actually implementing this type of service in Dojo (should be 
availabe in 1.2) that uses a CRUD API abstraction (the Dojo Data API) so 
that changes can be stored in local storage as a write-back cache for 
modifications being sent to the server with REST methods (POST,PUT, and 
DELETE); hence, synchronization is performed automatically, no effort 
required by authors. It looks AtomDB is doing something very similar (and 
maybe even compatible). However, while I definitely a big advocate for this 
write-back RESTful approach, here are some concerns I would have with this 
approach being standardized in HTML5:

1. A fairly comprehensive solution can be implemented JavaScript with 
existing and emerging (based on functionality in HTML5 or Gears) 
2. Web applications are increasingly moving away from XML towards JSON data 
interchange. The Dojo REST offline synchronization module is designed 
largely for JSON. It seems anachronistic to standardize on XML-based data 
model, it would be starting to be outdated by the time people started using 
3. If think this is too early to attempt to standardize on something like 
this, especially considered that we have emerging JavaScript 
implementations. In general, if libraries can implement a feature, I think 
there is a lot of benefit in letting JavaScript implementations break the 
ground so that the standards can be advised by the successes and failures 
before attempting to codify. This is especially true for very high-level 
features like this.

I think greater value can be found in pushing for and advocating standards 
that provide the important underlying features that can make this type of 
functionality possible or more efficient to implement for JS/web developers:

1. Offline Local Storage - Obviously this is the most fundamental part. 
Kudos to HTML 5 for incorporating this functionality.
2. REST communication capabilities - Of course we already have full REST 
interaction capability with XHR, but in the cross-site realm, the 
capabilities specified by CS-XHR will be invaluable for these type of 
applications (and another reason why XDomainRequest falls far short of being 
useful). The cross-site access control proposal will be very valuable 
3. JavaScript object monitoring and control - I think that another important 
aspect of developing these type of applications is being able to provide 
interaction based around normal JS object interaction; getters and setters 
is the tool we are looking for, see the efforts in ES3.1 and ES4 to 
standardize this functionality.

Received on Saturday, 21 June 2008 16:11:17 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:10 UTC