RE: Evolving AppCache discussions

> -----Original Message-----
> From: Adrian Bateman [mailto:adrianba@microsoft.com]
> Sent: Wednesday, September 26, 2012 7:48 AM
> To: Robin Berjon
> Cc: HTML WG (public-html@w3.org); Paul Cotton; Sam Ruby
> (rubys@intertwingly.net); Maciej Stachowiak (mjs@apple.com)
> Subject: 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.
> 

I agree. There is a lot of common support across browsers, though the feature can be aggravating to use, and could benefit from specific developer guidance in the current form. But we believe it is an important feature, as (I guess) the currently most-deployable approach to packaged/installable Web apps. 

> > 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)
> 

I believe that what AppCache enables is an important goal for the Web platform, and will be sought in some form or other by vendors, so it's in W3C's benefit to promote evolution of it effectively. If an extension spec enables a quicker evolution and more consistent implementation it makes more sense to me. The only question I have is whether the existing spec would stay inside HTML5 (and new work done outside, which seems like a fork) or be extracted at the same maturity state (in terms of the W3C process) as AppCache is now?

Received on Wednesday, 26 September 2012 17:32:24 UTC