Re: [Fwd: Offline data synchronization API]

I am happy to learn of Dojo's interest in offline auto-sync.

See my answers below.
Kris Zyp wrote:
> 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) 
> technologies.
Would it be fair to call a solution that needs an application switch to 
use locally cached data as comprehensive? The use cases we are trying to 
enable using AtomDB cannot be developed using pure JavaScript. We have 
already explored that path earlier and only after that explored a more 
browser-native .
> 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 it.
If the model is suitable, XML or JSON will not be the hurdle that 
remains in our way. It is equally possible to develop a model around 
JSON. At the moment, we have chosen XML since there is no standard 
around JSON publishing like Atompub.
> 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.
We have a good reason to try this now as opposed to a few years down the 
path. Certain companies, including those doing mobile operating systems, 
have already been promoting proprietary synchronization and local data 
access models for some time now. Like water, the pent up demand for 
off-line data is likely to flow where there is a path for it. There is a 
risk that deferring standards at this point lets establish de-facto 
competing technologies that only make it harder to standardize later.
>
> 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 indeed.
> 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.
>
> Thanks,
> Kris
>
>

Received on Saturday, 21 June 2008 23:37:30 UTC