- From: Robert Burns <rob@robburns.com>
- Date: Fri, 24 Aug 2007 03:52:14 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-html List <public-html@w3.org>
Hi Ian, On Aug 23, 2007, at 8:42 PM, Ian Hickson wrote: > [...] > > So I read through all the offline Web app discussions: > > http://www.whatwg.org/issues/#filesystem > http://code.google.com/apis/gears/api_localserver.html > http://www.campd.org/stuff/Offline%20Cache.html > > ...and various others. > > > USER INTERACTION SCENARIOS [...] > OTHER NEEDS [...] > QUESTIONS [...] > IDEA [...] I think that the use cases, needs questions and ideas contained in this message are interesting and point to many worthwhile features. However, I wonder whether it is something we should be working on right now. It's not entirely clear from your message, but much of what is proposed here looks to me to belong in a separate specification or at the very least a separate chapter of the HTML5 specification. In either event, it concerns me that by taking up features like this now, we're letting ourselves succumb to feature creep. It is also not clear, from this message, precisely what the scope of the syncing we're talking about. Is this syncing of the entire page and all of it's sub-resources. Or are we more talking about updating resources where there's a clear separation in the data's source. In other words, the document data is split in two: one portion of the data always comes from the server-side; the other portion of the data always comes from the client-side. In this scenario conflicts are eliminated since the server is simply updating the client and the client is simply updating the server. Certainly updates from the server may be dependent on data from the client (and vice versa), but the chunks of data each remain in their own realms. Let me provide an example where this separation is no longer possible to help illustrate what I'm talking about. Consider a document like that of a wiki page. When a user, user 'A', is offline, the user may be editing that document. At the same time other users may be committing changes to the document since they are already online or they have since returned to online status. Now when user 'A' returns to online status, the updating client-to-server and server-to-client sync involves potential conflicts in the synchronization process. While this is a clear-cut example of a synchronization conflict problem, I fear that even other more subtle cases exist where a user may reach dead-ends or continue to use an webapp beyond a state where synchronization can occur without conflicts. This would require some very detailed specification. You may say that this conflict resolution is a problem already. However, it becomes a bigger problem when offline editing occurs. Increasing the length of intervals between updates makes the problems with conflicts more serious. Such cases may be beyond the limits of what you're seeking to propose here. I could not tell from what you wrote. However, it does concern me that even in the case of clearly separated data, this is a big topic that might be better addressed in a separate recommendation or much later on in our WG deliberations. To take up entirely new features like this when we have so many issues and loose-ends to address that are related to existing features seems unwise. I'm worried such feature creep could end up delaying our deliverables indefinitely. Introducing this feature now is a good example of how the FIFO approach guiding our WG deliberations is not the way to go. Adding a web page for taking a popular opinion poll on the issues is also not helpful since many of the popular items will be the most ambitious and most susceptible to feature creep. I think the most useful way to organize our deliberations would be to do so based on the reviews conducted by the members of this WG. Since our goal is an "incremental revisions to the HTML specification.", it would be best to leave these major revisions for later consideration. Take care, Rob
Received on Friday, 24 August 2007 08:52:33 UTC