Re: DataCache API - editor's draft available

This is very encouraging. It sounds like we agree in principal that the best
place for the features represented in the DataCache proposal are extensions
to the AppCache corner of the world.

My preference would be to keep the official AppCache spec stable right now,
but to begin designing those extensions sooner rather than later. This would
help inform the architecture of AppCache implementations underway by browser
vendors today, and help better inform application teams of what to expect as
well. The DataCache proposal is a great starting point.

In a sense, specify these extensions on a "development branch" of the spec.

On Wed, Jul 22, 2009 at 10:56 PM, Ian Hickson <> wrote:

> On Wed, 22 Jul 2009, Adrian Bateman wrote:
> >
> > My preference would be to see this functionality proposed as an
> > evolution of AppCache. While I can't commit that we would implement it
> > any time soon, it would be included in our considerations and at the
> > very least if we implement AppCache we would try to ensure any
> > architecture we select wouldn't preclude these extensions in the future.
> > With work on the HTML5 spec trying to get it locked down towards a Last
> > Call, adding new features to that document is clearly less desirable and
> > I understand Ian's reluctance to incorporate extensions there.
> My preference in general would be for us to wait until we have stable,
> well-tested implementations before adding more features to appcache, but I
> certainly think that on the long term, appcache should be extended to
> support more than it does now. As it stands, the model is quite
> extensible, so I think it would be relatively easy for us to move in that
> direction in the future.
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 23 July 2009 16:34:24 UTC