RE: Caching breakout session at TPAC

Hi Nikunj,
 
I find the subjects of programmable caches and local http servers highly
interesting for the browser. The below comments and questions are from a
quick read-through of the supplied links, so please excuse any
misunderstandings:
 
1) API orthogonality
The spec invents yet another caching mechanism and "storage area". Have you
evaluated the possibilities to build the suggested functionality by
enhancing and combining existing APIs and features such as the regular HTTP
cache, AppCache, localStorage, etc?
 
2) "Data cache" naming
Your examples mention data in the cache such as images and blog posts. But,
the cache would work as well for application code resources such as script
files, wouldn't it? 
If so, would it be better to name the cache along the lines of its
programmability or flexibility, rather than "Data"?
 
3) Specification naming wrt Embedded Local Servers
I find the local servers to be somewhat on the border-line of the topic of
data caches, which seems to be confirmed by the specification's section
headings:
  4. Programmable HTTP Processing
    4.2 Data Caches
    4.3 Embedded Local Server
Would it be more appropriate to name the spec "Programmable HTTP
Processing", or to move the local server to its own spec?
 
4) Cache groups
It took me a little time to grok the meaning of data caches and data cache
groups, and my current understanding is that a data cache group is really a
"versioned cache", where the "versions" correspond to specific data cache
instances in the spec. I think it may be better to instead talk about one
cache with many versions, as this concept is probably more known to readers.
 
5) Explicit and event-loopy API design
I see that you have taken great care to make an API that allows to have full
control over concurrent cache state changes, through event-loopy transaction
callbacks and explicit cache upgrades ("swap"). Your example (below) for
adding a new uri to the cache first has a transaction callback that runs the
capturing at a suitable time, but which doesn't result in the current cache
being updated. Instead another callback, an "onready" event handler, needs
to be added where the updated cache is explicitly swapped in:
document.body.addEventListener('onready', function(event) {

  event.cache.swapCache();

  ... // take advantage of the new stuff in the cache

});

cache.transaction(function(txn) {

  txn.capture(uri);

  txn.finish();  

});
I think I understand your motivations on wanting to offer fine-grained
control like this, but do you have any thoughts on the above getting a bit
verbose for simple use-cases?
 
6) Transaction API
I haven't followed the discussions on WebStorage/WebDatabase/WebSimpleDB
lately, but is the transaction style in Data Cache adhering to any consensus
achieved in this area?
 
7) Sync API naming
There are several methods that are mirrored as synchronous versions, f ex
openDataCache and openDataCacheSync. Is the "Sync" suffix an upcoming
standard pattern for this duality?
 
8) Embedded Local Servers API
I think there will probably (need to) be long and hard discussions about
what a web server API inside a web browser should look like ;-), but to
start things off I'd like to say that I like that you are keeping it simple.
As we have XHR for client functionality in the browser, it might be nice to
have some API overlap with that, f ex naming the HttpResponse.bodyText
property "responseText" instead. But I see the dilemma with wanting the same
property name on HttpRequest, so maybe the current writing is better.
BTW, for inspiration on a simple JavaScript web server API running in a
single-threaded event-looped environment you may want to look at Node.js
<http://nodejs.org/> http://nodejs.org/.
 
Best regards
Mike Wilson
 
Nikunj R. Mehta wrote:



Posting for those not in HTML WG but interested in this topic. 

Thanks,
Nikunj


Begin forwarded message:


Resent-From: public-html@w3.org
From: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>
Date: November 6, 2009 8:12:50 AM PST
To: HTMLWG WG <public-html@w3.org>
Subject: Caching breakout session at TPAC

For the breakout session on "Caching" yesterday, I put together a small set
of slides [1]. These slides on caching techniques for off-line Web
applications include use cases not adequately supported by HTML
ApplicationCache. These use cases are intended to be supported by the
WebApps DataCache [2] spec.

Thanks for the interesting questions and spirited discussion at the breakout
session yesterday.

Nikunj
http://o-micron.blogspot.com

[1]
https://docs.google.com/fileview?id=0B0rjI-BMFJwBYzNhYTYyNWQtNGFhZi00N2MxLWI
yNDMtNGJhZjA2Y2ZhNzRh&hl=en
[2] http://www.w3.org/TR/DataCache/