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
