- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Fri, 1 Jan 2010 11:04:08 -0800
- To: Joseph Pecoraro <joepeck02@gmail.com>
- Cc: "public-webapps@w3.org WG" <public-webapps@w3.org>
(Adding back public-webapps list. Apologies for unintentionally leaving it out on original reply.) On Dec 16, 2009, at 6:32 PM, Joseph Pecoraro wrote: > [OFF LIST] > > Either you responded directly to me, or it has not shown up yet in > the Mailing List's archives. Either way, the mailing list is not in > the CC field for this or any of the other "Correction" replies. Was > that intended? The most recent, CacheTransaction email did include > the list. > > >>> - Event Names and Cache Host Ambiguity >>> I think "ready" and "error" are overly generic names for events >>> fired on the "cache host". Maybe better names would be "cache- >>> ready" or "cache-error". >> >> I agree that the names are generic. However, these are defined on >> the DataCache interface and, hence, there are no conflicts with >> existing names. I am adding event handler definitions for this >> purpose, which matches the expectations for DOM Level 3 Events. > > Before they fired at the "cache host", which you just clarified as > "document". The editors draft still says that they fire at the > "cache host". I still think that it is too generic of a name. > > Firing at the document, to the casual observer, it is entirely > unclear that this is a cache event: > > document.addEventListener('ready', ..., ...); > > The approach that Application Cache took, as that it made the "cache > host" more obvious. That is much, much clearer: > > applicationCache.addEventListener('updateready', ..., ...); No new events are defined on the applicationCache in the revised spec. > > I heard about potential changes to merge ApplicationCache and > DataCache. I am re-reading the Application specification tomorrow > and I'll be able to make more comparisons. Do you really intend to > put a 'ready' event on the document? > No. > >>> The specification is also ambiguous on what exactly the "cache >>> host" should be. Claiming: >> >> The model's definitions are correct. This is based on HTML5's >> AppCache and I would recommend not changing those. The algorithms >> are now updated to be consistent. > > Thank you for clarifying. I'll have to restructure my thinking, as I > had sided with "window". I'll be updating my library tonight. > > >>> - 4.1.1. Examples >>> http://dev.w3.org/2006/webapi/DataCache/#examples >>> The first example seems to be out of date for a number of reasons. >>> >>> [[ >>> var uri = ... >>> var cache = window.openDataCache(); >>> 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(); >>> }); >>> ]] >> >> This example has changed for other reasons. > > But to be clear (since now none of the examples show a listener) it > would be the following: > > document.addEventListener('ready', ..., ...); > > > > Thanks again, > Joseph Pecoraro Nikunj Mehta http://blog.o-micron.com
Received on Friday, 1 January 2010 19:06:44 UTC