Re: Evolving AppCache discussions

Hi Adrian,

thanks for getting this discussion started.

On 07/09/2012 18:45 , Adrian Bateman wrote:
> My proposal is that this discussion should be continued in the HTML
> WG where the current AppCache API is specified. Since there are some
> people who wish to participate in this work but only engage in this
> one activity, the consensus of our small group in Mountain View was
> to propose a new mailing list (public-html-appcache) to host the
> discussion (in a similar way to the public-html-media list). We also
> agreed that we should start with the current AppCache feature and
> evolve to solve the issues we have identified.

I don't have a strong personal preference about how the work is 
conducted, but any option that helps generate the greatest participation 
from people who have a strong interest in the topic seems like a good 
direction. The Media TF does indeed appear to be very functional and 
might serve as a model.

> I would like to propose such a mailing list and, in my view, this
> work should be part of HTML.next to ensure that it does not block
> progress on HTML5.

I believe that the discussion on the logistical details of how to 
organise this should not block talking about other specifics.

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.

The AppCache feature is rather intricately embedded into the current 
spec and therefore somewhat difficult to extricate, but as we all know 
things that are impossible just take longer. There may be a middle 
ground in which some of AppCache's interactions may remain in the spec 
as hooks while the concrete mechanism is left to the extension spec (not 
a wonderful approach, but I want to list the options).

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

WDYT?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 25 September 2012 16:09:01 UTC