----- Original Message -----
From: "Ian Hickson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2007 6:42 PM
Subject: Offline Web Apps
(If you reply, please only include one of the mailing lists in your
reply. Thanks.)
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
It seems like we are talking about the following kinds of scenarios:
1. User goes to a page, then, without closing the page, goes offline
and uses it, then goes back online and continues to use it. The
page and its subresources are always at their most
up-to-date. Interactions with the page while offline are synced to
the server when going online.
2. User goes to a page, then closes the browser. User restarts the
browser while offline, and goes to the page. User restarts the
browser again while online, and goes to the page. The page and its
subresources are always at their most up-to-date. Interactions with
the page while offline are synced to the server when going online.
3. Same as 1 or 2, except that the user is not online for long enough
to fully download the updated resources. The application doesn't stop
working, it is still usable the second time the user is offline.
OTHER NEEDS
We also seem to have the following requirements:
* Some way to specify what pages are needed while offline, even if
the page doesn't link to it.
* Some way to handle two offline Web apps both using the same
secondary resource, if we have some sort of versioning scheme. (So
you can update the two apps independently without breaking either
despite them using the same resource.)
* Resilience to updates -- if the page is open when you go online and
there's an update pending, or when you go online just as you're
loading the page (common with wireless networks, since you're
likely to take a few seconds to connect and your browser is often
ready beforehand) and there's an update pending.
* Resilience to broken updates. (More than the reload button?)
* There needs to be a way for the application to talk to the server
without talking to the offline cache.
* The API should be simple, both to authors on the client side, and
to authors on the server side, and to the end user, and ideally to
the implementors (and to me, the spec author!).
There are two distinct types of applications (in context of this topic)
1) Online web applications.
2) Occasionally connected web applications (OCWA).
These two groups differ significantly in their design.
So what exactly you are trying to make "offline aware"?
1) Online web applications - to make transparent features on UA level
that allow this group of apps to work offline.
2) To extend UA feature set to support occasionally connected web
applications - applications that work offline as a primary operational
mode. These applications require client side storage and other forms
of persistence.
I don't think that making online web applications "offline aware"
makes any or significant sense. Or even feasible as they use
data flow (RPC, aka AJAX) that implies active server.
I propose to clarify first what we are trying to solve.
Andrew Fedoniouk.
http://terrainformatica.com
