- 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