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

[Aaron Whyte]

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/38295c43/attachment-0002.htm>