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
