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

Re: DataCache API - editor's draft available

From: Jeremy Orlow <jorlow@chromium.org>
Date: Wed, 22 Jul 2009 16:10:52 -0700
Message-ID: <5dd9e5c50907221610l4d6eef11od37d0179300b049@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: "Nikunj R. Mehta" <nikunj.mehta@oracle.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.


I've talked to several people here at Google (including people who have
worked on Gears) and I think we all agree there are some good ideas in
DataCache, but we also agree that they should be framed into the AppCache
model.  Unfortunately, I don't think anyone has any precise ideas on how to
do this yet.  I think it's safe to say that we'd also be glad to review and
provide suggestions/experience.
Received on Wednesday, 22 July 2009 23:11:31 GMT

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