- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 22 Jul 2009 16:10:52 -0700
- 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>
- Message-ID: <5dd9e5c50907221610l4d6eef11od37d0179300b049@mail.gmail.com>
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 UTC