[whatwg] Offline Web Apps

[Robert O'Callahan]

I haven't had time to study Ian's proposal properly yet, sorry. But some
easy comments:

On 9/20/07, Maciej Stachowiak <mjs at apple.com> wrote:
>
> > Upgrader:
> > Create a hidden browsing context.
> > Load the upgrader in it.
>
> I don't like this whole upgrader idea. Parsing HTML and CSS and
> executing JavaScript seems like an inefficient way to do an app
> update. I think it is reasonable to require a manifest file for
> multipage apps, and writing an HTML/CSS/JS upgrader that can cover all
> pages of a multipage app does not seem significantly easier than
> creating a manifest file. The implicit manifest idea seems handy as a
> quick way to handle one-page apps but it does not seem reasonable for
> the multipage case, and this would obviate the need for an upgrader.


I totally agree with this.

> Just before onload, fire an 'upgrading' event to every instance of a
> >  top-level page using a cache with the same identifier.
>
> Whether or not there are upgraders though, I think events should
> dispatch when a manifest-based upgrade either completes or fails (and
> perhaps also when the upgrade starts).


Agree...

> The event has a handle to the Window object of the hidden browsing
> >  context.
> > After every 'upgrading' event has been fired, the 'load' event must be
> >  fired on the upgrader.
> > After that happens, if any of the aforementioned instances are still
> >  using old versions of the cache, then the user agent may inform user
> >  they can reload to update.
>
> I think it would be preferable to let the apps upgrade themselves
> instead. They could choose to use location.reload() if they are not
> holding any interesting state, or they could offer to save the user's
> state before doing this, or they could make some alternate call that
> requests all new resource loads for this instance should come from the
> freshly upgraded cache, which would let it perform an upgrade manually
> preserving current state if feasible.


Agree.

> The Upgrader can do such things as updating the database schema
> > between
> > versions, and when there are multiple instances running, it allows
> > them to
> > negotiate who will do that work instead of it happening several times.
>
> I would suggest instead that the instance that triggered the upgrade
> be given a special event so that it can do this and could optionally
> present in-page UI while doing so. This seems simpler than adding a
> hidden browsing context. Changing the schema may require pausing other
> instances, however, if there is no way to lock the database.


Agree.

> Modal alerts (window.alert, .prompt, etc) in the background page can
> > either raise an exception, be ignored, drop a message to a console, or
> > possibly display a message over the top of the foreground app's
> > browsing
> > context.
>
> To avoid such complexities it would be better to avoid the idea of a
> hidden upgrader. And in-page UI could be more tasteful than prompts or
> alerts.


Agree.

I'm not sure if an API to introspect what is currently in the cache is
> needed. I can't think of a use case off hand. But both the Google
> Gears LocalServer API and the Mozilla offline API have this.


Two different use cases:
-- If you can programmatically force URIs into the offline cache, then you
want to be able to enumerate the resources in the offline cache, otherwise
there is no way to reliably remove unneeded resources (especially if there
was an older, buggy version of the app that may have loaded resources from
unexpected URIs).
-- Several Web app authors have asked for the ability to test whether a
resource is cached, for their online apps. For example, when you're zooming
in and out of a map, the application could choose which tile(s) to use for
the animation by scaling them up or down. This would also be convenient for
offline use, where a resource might not necessarily be in the offline cache
but you could use it if it happened to be available.

A la the Google Gears API, I also think a feature is needed to do
> something useful with <input type="file"> when offline, to save a
> resource for later upload to the server. Preferably this should not
> require round-tripping the data through an ECMAScript string or number
> array, or it will be too inefficient to work for large files.


Actually we have an experimental API for this now. See here:
http://mxr.mozilla.org/seamonkey/source/dom/public/idl/html/nsIDOMNSHTMLInputElement.idl#55
http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFileList.idl
http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
The core is:

  readonly attribute DOMString fileName;
  readonly attribute unsigned long long fileSize;

  DOMString getAsText(in DOMString encoding);
                                  // raises(FileException) on retrieval
  DOMString getAsDataURL();
                                  // raises(FileException) on retrieval
  DOMString getAsBinary();
                                  // raises(FileException) on retrieval

These should be self-explanatory.

I guess this isn't great for really huge files, but multi-megabyte files
should be OK on most machines, and it avoids having to deal with a
client-writable "cache". It obviously has some interesting uses for online
apps as well.

Any thoughts on that?

I also don't see how apps that require login will be able to work
> offline. Do you need to make sure to check the appropriate "remember
> me on this computer" checkbox (perhaps not desirable for the security-
> conscious, and not available on all apps in any case)? Do you get to
> access the app when offline without having to go through login at all
> (which seems like a security issue)?


If your app is available offline then the data is stored locally, and there
is no way to secure that data against a determined someone who has access to
the user's browser profile, other than by encrypting all the application's
private data with some password that the user has to provide. I'd rather
have the OS encrypt the entire file system and protect that with the user's
logon password, or if that's no good, the browser could encrypt its user
profile data. Against casual data theft, the app can request a password,
hash it, and check it against a stored password hash.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070921/ac953073/attachment-0001.htm>