Re: DataCache API - editor's draft available

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:
>>> 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 paper talks about flexible client-server architecture in section  
2.1:
[[
The roles of clients and servers as well as the application  
functionalities can be dynamically relocated. The distinction between  
clients and servers may be temporarily blurred for performance and  
availability purposes.
]]
Further, the paper identifies one of the mobile file systems as Coda  
in Section 3.4 [1]. If you were to read the Coda paper, you would see  
the following text in its section 3.2. By the way, Coda was first  
conceived in early 1987 at CMU by Prof. M. Satyanarayanan's group.
[[
Individual replicas are not normally visible to users or application  
programs. All they see is an ordinary file system mounted at /coda.  
This illusion is created by the Venus cache manager on the client.  
Venus intercepts all file references to /coda, discovers which servers  
hold replicas of a volume and fetches file and directory data as  
necessary from those servers, and manages cache copies of this data  
using files in the local file system as containers.
]]
>
> 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?

Interception provides for the ability to introduce application- 
specific code that in emulating the server during disconnection.

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

An application can choose to use a library via which application- 
specific code is tied to the interception, but this is not necessary.

> Alternatively, is it application specific code that will be hand  
> written for my use case every time?

Generally speaking, yes. However a certain class of applications may  
choose to use a protocol such as Atom which generalizes the server  
behavior in terms of a specific set of semantics. In such a case, it  
may be possible to share a single library across applications that may  
do the interception.

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

This is precisely where the application programmer needs to make a  
call - do I want to offer this functionality to a user when they are  
unable to access the network. If not, then skip the rest and return  
with just an error message.

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

For those application behaviors, that require HTTP requests, that are  
to be supported off-line, I need to figure out what the off-line  
response should be. Then I have to translate this in to JavaScript  
code and attach it to interceptors. Certain application developers  
will be smart about out how to move code from the server environment  
to a client environment. Some developers will figure out an automated  
process for doing so, whereas others will be able to do so with manual  
support and computer guidance. In some cases, neither may be possible.

> Or is there a library I can just plug in that, with some  
> configuration, does that for me?

For example, Oracle's and prior to that Siebel's technology could  
situate application behavior to run on either client-side or server- 
side. The same behavior could be executed on either tier without a  
programmer having to write it twice or differently for the two  
situations. However, this is not in the context of HTTP or JavaScript.  
However, I expect that application developers who care so much about  
mobility would be able to come up with such libraries that could offer  
code portability and client-side server emulation without requiring  
separate programming for both sides.

> 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?"

I don't want to say that someone is out of luck. There is some  
knowledge of what the server will do with requests. So long as you can  
emulate that behavior in JavaScript, you are in the game. It is only a  
question of how much effort may be involved in producing the required  
JavaScript.

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

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

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.

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

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

>
> Cheers,
>
> Adrian.

[1] http://portal.acm.org/citation.cfm?doid=507052.507053

Received on Monday, 20 July 2009 20:45:59 UTC