Re: Archive API

On 9/11/12 6:29 PM, "Andrew Betts" <andrew.betts@ft.com> wrote:

>> 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).
>
>Obviously transporting base64 encoded data is not ideal, so any
>solution that enables reliable offline caching of atomic groups of
>dynamic content is going to potentially avoid the need for us to
>continue doing that - and it certainly doesn't do anything for us in
>terms of download performance (other than avoiding a complete app
>cache reload, which I guess you might be referring to as the current
>alternative).

I was referring to latency cost of downloading images one by one rather
than having them all grouped in a single file.

>I agree with Jake's use cases, the concept of editions and core
>framework as distinct and atomic groups of cachable data is in line
>with our requirements, especially for a weekly publication such as The
>Economist.

Do these weekly publications carry their own code (say for example d3.js
data visualization)? Anyhow, I think that's a use case we should cater for.

>The FT is more likely to apply atomicity at the article
>level, with a package comprising HTML plus a number of content images
>or media files.
>
>In any case, I'm not sure this is relevant - as far as I can tell this
>API doesn't in itself enable the Zip file or any of the unzipped
>contents to be stored persistently

A zip file is just a blob, so storable as is (or unzipped, your choice) in
IDB.

>(which is presumably what they
>intend you to use the File API for), unless you take the view that
>this API enables us to transfer the responsibility for atomic grouping
>of resources to the application developer and remove that feature from
>app cache, on the basis that you can implement it by telling appcache
>to cache a single zip file.

Oh. No. I was absolutely not suggesting using Archive API as a replacement
for transactions in AppCache.

It merely seems like an adequate solution for some of the use cases we
described, which was worth pointing out.

>Assuming we're not going to do that, I think it's at best solving a
>related but distinct problem that might be part of the same high-level
>objective (eg implementing a game app).

Absolutely. Hence the above wording.

--tobie

Received on Tuesday, 11 September 2012 16:53:30 UTC