Re: Fixing appcache: a proposal to get us started

One feature I'd like to see is respect for compression headers. I've got an
app which results in a 30Mb app cache, but it's only 8Mb over the wire due
to GZIP compression. I'd much prefer the appcache to see that the content
was served compressed, cache it compressed, and "serve" it to the browser
offline compressed too.

Whilst not strictly part of a JS API, it would probably be a worthwhile
"note to implementors" that the preferred behaviour is to store and "cache"
with the same compression headers with which the content was originally
served.

Another approach would be to modify the appcache manifest with a "compress"
property per item to cache, or perhaps transparently compress the entire
appcache for a given manifest within the browser (totally transparent to
the user/developer/API).

Either way, it'd be nice to prevent the scenario of downloading 8Mb content
and resulting in a 30Mb cache.

N




On 26 March 2013 08:48, James Graham <jgraham@opera.com> wrote:

> On 03/26/2013 08:02 AM, Jonas Sicking wrote:
>
>  Another "feature" that we are proposing is to drop the current
>> manifest format and instead use a JSON based one. The most simple
>> reason for this is that we noticed that the information we need to
>> express quickly became complex enough that using a format with simple
>> parsing rules was beneficial.
>>
>> A format based on extending the current appcache format would be no
>> problem for a UA to parse. However the complexity that we need to
>> express resulted in something that's too hard for a human to manually
>> write, or for a human to understand when looking at somebody else's
>> manifest in order to learn.
>>
>> The simple parsing rules for JSON seemed like a better fit. It also
>> provides more of an opportunity to extend the format in the future.
>> JSON also has advantages when it comes to creating APIs exposed to
>> webpages for interacting with appcaches. More about this below.
>>
>
> Some slightly trivial feedback: I am worried about using a format with no
> support for comments. I agree that some hypothetical JSON+comments format
> would be a good fit, but without the ability to document complex rulesets,
> it seems like we are going to create a maintenance nightmare.
>
>