- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Thu, 16 Jul 2009 16:45:53 -0700
- To: Adrian Bateman <adrianba@microsoft.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, public-webapps WG <public-webapps@w3.org>
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. Nikunj http://o-micron.blogspot.com 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, though. 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 benefit. * 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. > [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
Received on Thursday, 16 July 2009 23:48:15 UTC