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: Tue, 21 Jul 2009 23:12:05 -0700
Cc: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, Jonas Sicking <jonas@sicking.cc>, public-webapps WG <public-webapps@w3.org>
Message-id: <D301A5F4-45D1-43AF-8CB4-63D41441F709@apple.com>
To: Adrian Bateman <adrianba@microsoft.com>

On Jul 21, 2009, at 9:15 PM, Adrian Bateman wrote:
>
> I don't think the problem is that we couldn't build yet another  
> cache that is similar but different to the AppCache that others are  
> already shipping so I don't think a reference implementation is the  
> solution. I think the problem is motivation - are there any use  
> cases that adding DataCache enables that couldn't otherwise be  
> implemented with what we already have and are those compelling  
> enough to complicate the platform with another cache mechanism.  
> Further, would we end up with conflicts between the AppCache and the  
> DataCache since they're currently not unified as far as I can tell.

[...]

> 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 is pretty close to my own point of view. I think the  
functionality offered by DataCache is interesting, but I'd be much  
more interested in putting it into Safari and WebKit if it was exposed  
as a set of extra AppCache features, rather than a competing and  
unintegrated separate model.

I believe AppCache can reasonably be extended to support the extra  
functionality of DataCache. For example, it should be possible extend  
the manifest format with a way to express that a certain URI should be  
served by script, and to give that script access to a static cached  
copy if it chooses to use it.

> 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.

I agree with this as well. I think extending AppCache is likely to be  
a more successful approach than building a full alternative. I will go  
further and say that if some of the advanced DataCache features were  
expressed as extensions AppCache, we would likely be very interested  
in implementing them.

Regards,
Maciej
Received on Wednesday, 22 July 2009 06:12:47 GMT

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