Re: Version identifier

> Are there any use cases that would see this feature being misused?

Good point. A reasonable size constraint on the value might be a good idea.

> However, on the whole, I think we have far larger fish to fry here

Very much agree. In isolation, reflecting a 'version' or 'id' attribute
just formalizes the adhoc version comment scheme and provides a slightly
less mysterious way of sampling that value from a running document. It's
"nice" but so what.

> Simple and easy to implement, but what's the use case?
> Agree about "bigger fish". We should get a use case for it and see how it
fits with the others.

One of the bigger fish to fry is making the appcache feature useful for
more than purely offline use cases. In some internal discussions about the
'prefer-online' setting, we were seeking a means of being able to load a
page over the network that could immediately load resources out of an
existing application cache. The way things currently are, prior to just
hitting the appcache, the manifest file of that existing cache has to be
validated which generally requires a server roundtrip. We were seeking
to eliminate that round trip and thought that more explicit versioning
could help...

   <html manifest="file" manifestVersion="2">

The thinking was if the existing appcache version matched, we could
retrieve subresources out of that appcache without any validation.


On Tue, Oct 30, 2012 at 2:06 AM, Jake Archibald <jaffathecake@gmail.com>wrote:

> Agree about "bigger fish". We should get a use case for it and see how it
> fits with the others.
> On 30 Oct 2012 08:53, "Andrew Betts" <andrew.betts@ft.com> wrote:
>
>> Agree that this has value - though there are a few possible complexities:
>>
>>  - If this is intended to replace the use of a comment for the version
>> number to trigger an upgrade, then we should be careful not to leave use
>> cases where the comment will still be used even though this new feature is
>> available (eg by adding constraints to the version which the comment
>> doesn't have)
>>  - In some apps, the identifier string in the manifest is user specific
>> (I think Jake does that..?) so I'd be wary of formalising the terminology
>> using the word 'version', since it may in practice serve other uses.
>>  Possibly ID would be more appropriate.
>>  - Are there any use cases that would see this feature being misused?
>>  This would be the only JS API into the actual content of the App Cache, so
>> I can see people setting something like 'version
>> {VERY_LONG_STRING_OF_JSON}' and using it as a data store.  No idea whether
>> there would ever be any compelling reason to do that, but if it's the only
>> way in, there's a risk that someone may find a reason to use it that way.
>>
>> However, on the whole, I think we have far larger fish to fry here.  In
>> practice, this is a solved problem, because if I really want to know which
>> version of the app cache I have, I could surely just explicitly cache a
>> script that sets some globals with the version data, and include that in my
>> page.  There are other use cases for which there is no elegant workaround
>> or no workaround at all.
>>
>> The goal of this group as currently stated is to produce use cases rather
>> than proposals.  I made an initial shot at documenting use cases [1] in the
>> London meeting notes, and we're waiting on Tobie's greater expertise in
>> spec development to improve them.
>>
>> Cheers,
>>
>> Andrew
>>
>> [1]
>> http://www.w3.org/community/fixing-appcache/wiki/Meeting_notes_14_August_2012#Use_cases
>>
>>
>> On 29 Oct 2012, at 22:38, Chris Wilson wrote:
>>
>> > It was discussed at the Mozilla-hosted meeting that a version
>> identifier, to help developers identify what appcache was in use, would be
>> helpful.  I wanted to make a simple proposal for that: a version token in
>> the SETTINGS section.  This would be the token "version" followed by a
>> single simple token string (not necessarily numeric; up to the developer
>> what they actually put in there), e.g.:
>> >
>> > SETTINGS
>> > version 1.0
>> >
>> > this would then be exposed this on the applicationCache object:
>> >
>> > readonly attribute DOMString version;
>> >
>> > Thoughts?
>> >
>> > -Chris
>>
>>
>> --
>>
>> ------------------------------
>> 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 Friday, 2 November 2012 20:42:00 UTC