There is a proposal in the w3c world that attempts to address this use case...<div><a href="http://dev.w3.org/2006/webapi/DataCache/">http://dev.w3.org/2006/webapi/DataCache/</a></div><div><br></div><div>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.</div>
<div><br></div><div><br><div class="gmail_quote">On Wed, Jul 22, 2009 at 5:14 PM, Aaron Whyte <span dir="ltr"><<a href="mailto:awhyte@google.com">awhyte@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<span style="font-family:Arial"><div style="margin-top:0px;margin-bottom:0px">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.</div>
<div style="margin-top:0px;margin-bottom:0px;text-align:right"><br></div><div style="margin-top:0px;margin-bottom:0px">Here's one way to sync a single attachment down to an offline-capable client, by abusing the app cache:</div>
<div style="margin-top:0px;margin-bottom:0px">1) Client creates a hidden iframe with the URL /manifestwrapper/<attachmentID></div><div style="margin-top:0px;margin-bottom:0px">2) Server responds with a tiny HTML page whose sole purpose is to deliver a manifest attribute, pointing to /manifest/<attachmentID></div>
<div style="margin-top:0px;margin-bottom:0px">3) The client requests the manifest, which has one URL in it: /attachment/<attachmentID></div><div style="margin-top:0px;margin-bottom:0px">4) Finally, the client requests the attachment and stored it locally.</div>
<div style="margin-top:0px;margin-bottom:0px"><br></div><div style="margin-top:0px;margin-bottom:0px">This isn't great, for a lot of reasons:</div><div style="margin-top:0px;margin-bottom:0px">- It makes it hard to uninstall an offline client, because there are potentially thousands of teeny manifests.</div>
<div style="margin-top:0px;margin-bottom:0px">- It's unlikely to scale well, since it's kind of abusing the browser.</div><div style="margin-top:0px;margin-bottom:0px">- It takes 3 server round trips to sync one attachment.</div>
<div style="margin-top:0px;margin-bottom:0px">- It can't be done from a worker thread, since an HTML page is needed to provide a manifest attribute.</div><div style="margin-top:0px;margin-bottom:0px"><br></div>
<div style="margin-top:0px;margin-bottom:0px">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.</div>
<div style="margin-top:0px;margin-bottom:0px"><br></div><div style="margin-top:0px;margin-bottom:0px">Gears has something just like this: <a href="http://code.google.com/apis/gears/api_localserver.html#ResourceStore" style="color:rgb(85, 26, 139)" target="_blank">http://code.google.com/apis/gears/api_localserver.html#ResourceStore</a></div>
<div style="margin-top:0px;margin-bottom:0px"><br></div></span>
</blockquote></div><br></div>