W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: DataCache API - editor's draft available

From: Michael Nordman <michaeln@google.com>
Date: Wed, 22 Jul 2009 18:39:06 -0700
Message-ID: <fa2eab050907221839y1a14576fi50e353280b3a1342@mail.gmail.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Adrian Bateman <adrianba@microsoft.com>, public-webapps WG <public-webapps@w3.org>
On Wed, Jul 22, 2009 at 4:00 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Jul 21, 2009, at 11:25 PM, Nikunj R. Mehta wrote:
>
>  On Jul 21, 2009, at 9:15 PM, Adrian Bateman wrote:
>>
>>  While it might not be the perfect solution (we know the web far from
>>>>> ideal and is a lot of compromise), this type of proposal would be a
>>>>> lot more compelling to me if I could say "This is what we have to
>>>>> add, this is how, and here are the use cases that make it valuable"
>>>>> with a roadmap for extending what people are already building
>>>>> instead of something brand new.
>>>>>
>>>>
>>>> Would you mind explaining the last point "with a roadmap for extending
>>>> what people are already building instead of something brand new." for
>>>> me? I would definitely strive to make the proposal more compelling.
>>>>
>>>
>>> What I'm asking for is a more unified proposal that says "If you have
>>> already implemented AppCache, here's what you add to make the same cache
>>> provide the additional functionality needed to enable these additional use
>>> cases." This will inevitably be a compromise from what a pure implementation
>>> looks like (your current DataCache spec, say) but lots of the web is
>>> necessarily a compromise because it builds on prior art that might not have
>>> been ideal but has been specified, built and deployed (and not always in
>>> that order).
>>>
>>> This would allow people to form a judgement about whether the additional
>>> use cases are worth the additional effort instead of whether the additional
>>> use cases are worth yet another cache. I think the ship has already sailed
>>> on AppCache and we can't undo that even if we wanted to and I don't think a
>>> competing solution is the right approach.
>>>
>>
>> What kind of extensions/changes to AppCache would be acceptable at this
>> point? In a previous exchange with Ian, he declined to consider DataCache
>> like extensions to ApplicationCache for HTML5, which might be the reasonable
>> thing to do. I can of course put together a proposal, but it would be good
>> to know from browser vendors what their preferences are in this matter.
>>
>> I am open to the idea of incrementally evolving AppCache to be more
>> supportive of DataCache requirements.
>>
>
> We'd be willing to consider implementing AppCache extensions in WebKit even
> if they were initially proposed in a separate specification from HTML5,
> assuming there was rough consensus among browser vendors that the extensions
> are a good idea.
>
> I think the ability to have a resource that is served by a client-side
> script would be an example of a reasonable extensions. I'm not totally sure
> how to recast all of the DataCache ideas to fit with the AppCache model. I'd
> be glad to review and provide suggestions, if everyone thinks this is a good
> idea.


Thank you for putting this proposal together. The Chrome team is willing as
well to consider adding extensions along these lines to Chrome. And several
app teams here at Google would be willing to put them to good use.


>
> Regards,
> Maciej
>
>
>
Received on Thursday, 23 July 2009 05:51:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT