W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [DataCache] "ready" CacheEvent and Related Questions

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Fri, 1 Jan 2010 11:04:08 -0800
Cc: "public-webapps@w3.org WG" <public-webapps@w3.org>
Message-Id: <05DB6213-EC9A-429E-861B-674A26BEC8A6@oracle.com>
To: Joseph Pecoraro <joepeck02@gmail.com>
(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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT