Re: Archive API

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

>On 11 September 2012 16:04, Tobie Langel <tobie@fb.com> wrote:
>>>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.
>
>Say the user visits a magazine site, the core framework needs updated,
>5 issues need updating, 1 issue needs removing (eg, past an expiry
>date).
>
>If the core framework updates, 3 issues update, 1 issue partially
>updates before the user loses their connection, the following should
>happen:
>
>* Framework and 3 updated issues are saved to the cache
>* Partially updated issue remains in its currently cached state (a
>partial update of an issue is unacceptable)
>* Expired issue removed from cache
>* Update will retry/resume at next cache check
>
>This is based on the assumption that a single issue depends only on
>the core framework
>
>If the core framework fails to update, 3 issues update, 1 issue
>partially updates before the user loses their connection, the
>following should happen:
>
>* All issues remain in their previously cached state - issues have a
>dependency on the core framework, the new issues may depend on changes
>to the core
>* Expired issue remains - the expiry of this could also be related to
>core updates
>* Update will retry/resume at next cache check

OK. I understand now. I was in no way suggesting this Archive API would be
used as a global solution, but to cater for certain use cases, such a text
content + pictures, or slides + video + transcript).

>> 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.

Oh, man! Autocorrect fail here: s/stingily/strongly/

Sorry about this.


>If we went for the worker-proxy solution, this could be one of the
>many ways devs handle updates & they could pick the one best suited to
>their situation. You're right, the zip thing would probably work well
>for games devs. Do we need a higher level solution that doesn't
>involve so much manual cache management? Or has the current spec shown
>that it's not possible without creating something more confusing that
>doing it manually?

I really think Archive API is targeted at solving a very tightly scoped
use case, that's orthogonal to AppCache, but that was brought-up during
the London meeting. I'm mostly thinking about Andrew's use case here,
where images are base64-encoded and transported as a string alongside the
main content for transactional purposes (and download perf).

--tobie

Received on Tuesday, 11 September 2012 15:32:12 UTC