[whatwg] syncing attachments to an offline-capable client?

[Michael Nordman]

There is a proposal in the w3c world that attempts to address this use
case...http://dev.w3.org/2006/webapi/DataCache/

There seems to be a growing consensus (on the public-webapps list) that the
feature set described in that proposal should be folded in as an extension
to the appcache. The draft encompasses some features that have historically
been mentioned for the appcache and are reflective of Gears.


On Wed, Jul 22, 2009 at 5:14 PM, Aaron Whyte <awhyte at google.com> wrote:

> Forums, bug trackers, mail programs, photo apps, etc. all have allow users
> to download attachments or view them inline in the browser.  An
> offline-capable app should be able to sync attachments down to the browser,
> as data.  There may be thousands of such resources for one app, added and
> removed constantly, as part of data synchronization.
>
> Here's one way to sync a single attachment down to an offline-capable
> client, by abusing the app cache:
> 1) Client creates a hidden iframe with the URL
> /manifestwrapper/<attachmentID>
> 2) Server responds with a tiny HTML page whose sole purpose is to deliver a
> manifest attribute, pointing to /manifest/<attachmentID>
> 3) The client requests the manifest, which has one URL in it:
> /attachment/<attachmentID>
> 4) Finally, the client requests the attachment and stored it locally.
>
> This isn't great, for a lot of reasons:
> - It makes it hard to uninstall an offline client, because there are
> potentially thousands of teeny manifests.
> - It's unlikely to scale well, since it's kind of abusing the browser.
> - It takes 3 server round trips to sync one attachment.
> - It can't be done from a worker thread, since an HTML page is needed to
> provide a manifest attribute.
>
> It'd be a lot better to have a JS API to capture new URLs.  Since they're
> web resources, it's tempting to associate this with the app cache.  But the
> update strategy is totally different from the app cache's, so a more
> data-centric object might be more appropriate.  And if it could be pure JS,
> callable from a worker, even better.
>
> Gears has something just like this:
> http://code.google.com/apis/gears/api_localserver.html#ResourceStore
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090722/b4427da0/attachment.htm>