Re: DataCache API - editor's draft available

Hi Adrian,

I am glad to explain the use cases further as needed.

I addressed Jonas' questions in separate messages, so I will focus  
here solely on your questions. Please see responses in-line.


On Jul 16, 2009, at 3:31 PM, Adrian Bateman wrote:

> On Thursday, July 16, 2009 2:43 PM, Jonas Sicking wrote:
>> Hi Nikunj,
>> So one of the things I've never fully understood with your proposal  
>> is
>> what usage patterns people are going to want to use this new API  
>> with.
> [snip]
> 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,  

Due to poor network coverage in the past, this pattern was not very  
valuable. However, as networks improve yet remain unpredictable, this  
pattern becomes more relevant.

For example, if the network is 95% unavailable for 90% of the time  
(e.g., when one is out-of-office), then it makes sense to have a fully  
disconnected architecture. However, if the network is only 25%  
unavailable for 25% of the time, then it is better to have an  
architecture that fully utilizes server resources whenever possible  
and downshifts to an off-line scenario when needed. This is the  
pattern used in DataCache.

> The other concern that I have is that this seems like an extension  
> to the AppCache support in HTML 5. The new part is the ability to  
> denote certain end-points that respond dynamically via script  
> including supporting verbs other than GET.

Besides the verb difference, there are others that I have previously  
stated on this ML and blogged about [2]. I will summarize for your  

* ApplicationCache does not allow programmatic inclusion of items  
(dynamic entries were removed some time ago). all data capture in  
DataCache is through an API, i.e., as a dynamic entry.
 ApplicationCache does not secure one user's private resources from  
another; DataCache requires the presence of a specified cookie
 ApplicationCache uses its own data format for identifying items for  
local storage and exludes any other formats such as JSON and Atom;  
DataCache does not have any format limitations
* ApplicationCache operates per its own refresh protocol and that  
excludes a different protocol, especially one that does not require  
all or nothing semantics for data versioning; DataCache has no  
protocol limitations.

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

> Cheers,
> Adrian.


Received on Thursday, 16 July 2009 23:48:15 UTC