Re: Archive API

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

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)

-- 

------------------------------
This email was sent by a company owned by Pearson plc, registered office at 
80 Strand, London WC2R 0RL.  Registered in England and Wales with company 
number 53723.

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