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

Re: DataCache API - editor's draft available

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 22 Jul 2009 16:00:59 -0700
Cc: Adrian Bateman <adrianba@microsoft.com>, public-webapps WG <public-webapps@w3.org>
Message-id: <BF02B13E-B124-4E0E-BE0C-9F443AF90A00@apple.com>
To: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>

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.

Received on Wednesday, 22 July 2009 23:01:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:17 UTC