[whatwg] Offline Web Apps
news at terrainformatica.com
Fri Aug 24 11:24:50 PDT 2007
----- Original Message -----
From: "Ian Hickson" <ian at hixie.ch>
To: <whatwg at whatwg.org>
Cc: <public-html at w3.org>
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:
> ...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
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.
More information about the whatwg