RE: Evolving AppCache discussions

On Tuesday, September 25, 2012 9:09 AM, Robin Berjon wrote:
> My first question is how do you see this work taking place at the 
> editorial level? By this I mean that it could be placed in the HTML.next 
> draft as a series of changes to the current model, or the current model 
> could be ripped out (in which case we would ship 5.0 without it, or at 
> the very least mark it as at risk - it's rather broken anyway) and put 
> in an extension spec.

What is currently in the spec is, in general, what people have implemented.
Certainly I believe that there is interoperability for at least most of
AppCache and it is in (limited) use on the web today. Having that written
down doesn't seem like a bad idea.

> The pros of having a separate spec are that it can ship on its own 
> timeline, and can perhaps more easily be the subject of focused work by 
> the group you are proposing to assemble around a separate list. The cons 
> are extra editorial work in the short term (which I reckon we can figure 
> out) and potential mismatches going forward (which I would hope we can 
> avoid by virtue of being implemented by exactly the same people).

Having said that, I'm always in favour of modularity and separate specs
make it a lot easier to hand a feature to an engineer for them to review.
In fact, we found a couple of minor issues in our implementation of AppCache
after we shipped that were directly caused by the fact that some requirements
are littered throughout the spec.

>From the people I've spoken to, most seem to be in favour of evolving our
way to a more useful AppCache and so I don't think it is essential to mark
the feature at risk and/or remove it from the spec. On the other hand, it
would be nice to iterate quickly as you suggest, perhaps as an extension
spec detailing the changes. Which is better may depend on exactly what
changes we want to make and hindsight is a wonderful thing. :o)

Cheers,

Adrian.

Received on Wednesday, 26 September 2012 14:48:42 UTC