RE: DataCache API - editor's draft available

On Monday, July 20, 2009 1:43 PM, Nikunj R. Mehta wrote:
> On Jul 17, 2009, at 9:31 AM, Adrian Bateman wrote:
> > On  Thursday, July 16, 2009 4:46 PM, Nikunj R. Mehta wrote:
> >> On Jul 16, 2009, at 3:31 PM, Adrian Bateman wrote:

...

> > Does the situation change if I am building an application from
> > scratch that wants to deal with network disconnections?
> 
> In that case, you should be able to take advantage of the presence of
> interceptors and write your code to move to the client when client-
> side execution is desirable. If this application is used in
> environments that do not support interception, then it will work just
> fine with server-side execution. Of course, the application won't do
> the right recovery when it is disconnected if interception is not
> supported.

Thanks for this and the preceding answers that I snipped. I'm not sure I find this model more compelling than the imperative equivalent, but okay. We can agree to disagree on which is more natural to web developers.

> > I understand that your DataCache proposal provides different
> > functionality to AppCache. I wasn't suggesting that they were
> > equivalent.
> 
> I am glad to see that you see a different set of functions offered in
> DataCache. Several commenters before you have taken the exact opposite
> position.

I didn't interpret the other responses I read in that way but I may have mis-read them. I thought they were making a similar point to my next one.

> > However, the AppCache as specified is getting implemented today (it
> > is in Safari and Firefox with other implementations on the way). The
> > problem I have is that I can't go implement AppCache and then add on
> > some new methods and alternative interception-path to get DataCache-
> > like features - I have to write a completely independent mechanism.
> > If I propose that we build AppCache and then DataCache, someone will
> > say, "Hang on, didn't we just build this - why do we need two?"
> 
> OK. I get that. I also consider this to be an important challenge for
> everyone concerned. I thought I would write a concrete proposal.
> Oracle could help out with building a reference implementation for
> multiple browsers and make its source code available.  What else can I
> do to help?

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.


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

Cheers,

Adrian.

Received on Wednesday, 22 July 2009 04:17:22 UTC