W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Offline Web Apps

From: Robert Burns <rob@robburns.com>
Date: Fri, 24 Aug 2007 03:52:14 -0500
Message-Id: <34B8EB81-1D7D-4362-8F6F-E6F02255A8DD@robburns.com>
Cc: public-html List <public-html@w3.org>
To: Ian Hickson <ian@hixie.ch>

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.
> 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  

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  

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,
Received on Friday, 24 August 2007 08:52:33 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC