RE: DataCache API - editor's draft available

On  Thursday, July 16, 2009 4:46 PM, Nikunj R. Mehta wrote:
> On Jul 16, 2009, at 3:31 PM, Adrian Bateman wrote:
> > I agree with Jonas and I'd like to understand the expected use cases
> > better too. I think I get the point that making the network access
> > seamless regardless of whether there is network connectivity or not
> > simplifies the network request code but seems to me to require more
> > complex interception code.
> 
> There is a tradeoff when adding the complexity of unreliable networks
> - either more complex client application code, or more complex client
> interception code.
> 
> In our experience, we have found the latter to be actually more
> manageable for cases where the interception and off-line serving is
> done in a relatively application-independent manner.
> 
> > This isn't a pattern that I can readily map to customer requests
> > we've received nor is it a familiar pattern to me personally.
> 
> DataCache's interception pattern has existed for a while. A good
> survey of mobile data management and transaction support has covered
> this pattern [1]. The discussion there is not limited to Web browsers,
> though.

I scanned through the paper you cite but it isn't clear to me which part of that is equivalent to your proposal. Is it possible to point out which section I should read more closely?

The pattern that isn't familiar to me is one where it appears that application logic is provided by interception. Given the generic nature of the Mobile Transactions paper you focus on application independence, are you proposing that the DataCache is part of a solution with no application specific code? In other words is there some "platform" component, whether  that be a JavaScript library or otherwise server-provided infrastructure, that operates generally at the interception point. Alternatively, is it application specific code that will be hand written for my use case every time?

When Jonas asks the question about how do you expect people to use this, what comes to mind for me is a question about a scenario. "I'm a web developer and I've built an application that makes XHR calls to exchange data with my server. I'd like to provide access to this application in situations where I am occasionally disconnected because of intermittent network connectivity. Do I now sit down and try to figure out what network requests I need to intercept and write JavaScript code for handling all of those requests? Or is there a library I can just plug in that, with some configuration, does that for me? Or is this something my server infrastructure should already support and if it does I just turn it on but otherwise I'm out of luck?"

Does the situation change if I am building an application from scratch that wants to deal with network disconnections?

> > On the other hand, it appears to me that it proposes an entirely new
> > programming model - did you consider an incremental approach that
> > modifies window.applicationCache? Did you have particular reasons
> > for rejecting that?
> >
> 
> Yes. I certainly considered window.applicationCache. I have previously
> proposed including additional things in HTML5, but the feedback was
> that the application cache could not be broken down in to any further
> primitives due to bootstrapping requirements [3].
> 
> I certainly feel that applicationCache can be composed with the
> primitives of DataCache + versioning. On the other hand, the converse
> is not possible due to ApplicationCache's:
> 
> a. strictly static manifest serving,
> b. lack of support for version-free resources, and
> c. missing authorization checks.

> [1] http://portal.acm.org/citation.cfm?id=992378
> [2] http://o-micron.blogspot.com/2009/04/how-is-bitsy-different-from-
> html-dojo.html
> [3] http://lists.w3.org/Archives/Public/public-html/2008Nov/0224.html

I understand that your DataCache proposal provides different functionality to AppCache. I wasn't suggesting that they were equivalent. 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?"

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.

Cheers,

Adrian.

Received on Friday, 17 July 2009 16:33:49 UTC