Re: Archive API

On 9/11/12 4:26 PM, "Jake Archibald" <jaffathecake@gmail.com> wrote:

>On 11 September 2012 14:30, Tobie Langel <tobie@fb.com> wrote:
>> Is this missing features for the use cases we are interested in?
>
>Currently appcache provides a transactional way to cache files, if any
>file listed in the manifest fails to download, the whole caching
>process fails. Unfortunately it's all or nothing, whereas Lanyrd/FT
>want to divide these up into groups. Eg, one group for the framework,
>then additional groups per issue (FT) or event (Lanyrd), I can imagine
>games developers wanting to do the same with levels.

Actually, game devs are the reason Archive API was cooked up.

>If the framework caches, but one of the events fails (eg loss of
>connection), we'd be happy with the framework & successful events
>caching. We'd also want to be able to add/expire additional events
>later.

I don't understand this.

>The zip file method provides the packaging, but isn't as efficient the
>current appcache system when it comes to updates.

Agreed. It's aimed mostly at static content (where "static" means "rarely
changing").

>If I want to update
>a js file I can change the manifest to point at the new js file. if
>I've been smart with caching headers, only the js file will be
>downloaded. The zip system means downloading the whole package again
>for any change, depending on the situation this could be a large
>download for a small change.

There are application-level workarounds. E.g. the app could download a zip
filed containing only the modified files (or even better, diffs) and
combine the content of the two zip files.

Overall feeling is while this matches some use cases, it certainly doesn't
match some of those you care most stingily about.

--tobie

Received on Tuesday, 11 September 2012 15:05:06 UTC