Re: [DataCache] General Comments and Correction for the New WD

On Jan 1, 2010, at 1:38 PM, Joseph Pecoraro wrote:

> Some driveby comments. There were a lot of changes, but these were
> just what I caught with a quick scan.  I can see you've put a lot
> of work into this, Thanks!
>
>
> ---- General ----
>
> - 4.1 Introduction
>  http://dev.w3.org/2006/webapi/DataCache/#datacache-intro
>
>  review policy says "(only for unsafe HTTP methods)".
>
>  Why discriminate? I could see an application wanting to review a GET
>  request. For example, an application which can be updated by multiple
>  clients. It may be useful to examine the data returned from a GET,
>  which may contain information data that the other clients POST/PUT.

Firstly, an application cache is shared by all those who have the same  
manifest (provided they are all in the same origin). Secondly,  
reviewing a GET response is easy to do with the oncapture event  
handler that is defined on transactions. Thirdly, the review policy  
can only be used through the offlinehandler, i.e., embedded local  
server, and activated by the user agent. Therefore, if an application  
wishes to review, it should be prepared to intercept. If it is not, it  
should use the [[captured]] events for examining data returned from a  
GET.

>
>
> - IDL Descriptions
>  HttpRequest#bodyText and HttpResponse#bodyText
>  http://dev.w3.org/2006/webapi/DataCache/#widl-HttpRequest-bodyText
>  http://dev.w3.org/2006/webapi/DataCache/#widl-HttpResponse-bodyText
>
>  The description of the DOMString is currently:
>
>    [[
>      This attribute, on getting, must return the entity body of this
>      HttpRequest object, if the body has a Content-Type of either
>      text/* or application/xml.
>    ]]
>
>  I think this is rather restrictive. For one, JSON data transferred
>  with the Content-Type "application/json" would be just as useful (if
>  not more so) as XML. For that matter, XML can be transferred with
>  different types. Take AtomPub for example, it uses
>  "application/atom+xml".
>
>  Is there a generalization that can be applied here? A white-list is
>  likely  overly restrictive, and not future proof.
>

I have changed the two descriptions so that there is no longer a  
restriction on the use of this attribute with specific MIME types. I  
have provided XMLHttpRequest style descriptions of these two attributes

>
> - Usefulness of incrementPendingUpdates / decrement
>  http://dev.w3.org/2006/webapi/DataCache/#widl-CacheTransactionRequest-incrementPendingUpdates
>
>  Is the number of updates useful, or even accessible? It seems as
>  though developers only really need to know if there are any updates
>  or not. A "dirty" flag boolean for instance.

The use case is that of a browser that doesn't keep multiple  
applications, i.e., Web pages open. When you use an application off- 
line and create dirty data in the cache, you want to provide an  
opportunity for that dirty data to be flushed to the server. Since the  
application may not have any way to communicate with a user that it  
has dirty data when the user agent is in a position to communicate  
externally, it is necessary for the user agent to keep track of the  
existence of dirty data. The count information merely provides some  
idea to a user as to how large the dirty data has become.

>
>
>
> ---- Events ----
>
> 4.2.1 Starting a transaction
> http://dev.w3.org/2006/webapi/DataCache/#starting-a-transaction
> updating event is a dead hyperlink. Did this get dropped?

The event has been dropped. I removed the obsolete reference  to it.  
The reason to remove this is to avoid confusing event handlers that  
are not used to the "DataCache" events for application cache objects.

>
>
> 4.2.4 Committing a transaction
> http://dev.w3.org/2006/webapi/DataCache/#complete-transaction
> updateready event is not mentioned elsewhere. Do you mean the  
> "ready" event?
>

Yes. This is updated now.

> 4.2.5 Aborting a transaction
> http://dev.w3.org/2006/webapi/DataCache/#abort-transaction
> error event is not mentioned elsewhere. Did this get dropped?

This is obsolete as well. Corrected now.

>
> I also noticed that a lot of the Events now trigger with the Event
> interface, and not the CacheEvent interface. Overall, I think the
> Event's have had the most changes in the last few revisions, and
> need to be cleaned up everywhere.
>

CacheEvent is used for the [[captured]] and [[released]] events only.

>
>
> ---- Typos ----
>
> 4.2.7 Asynchronous reuests
> http://dev.w3.org/2006/webapi/DataCache/#request-events
> As you can see, it should be "Asynchronous requests" in both the Table
> of Contents and the section's header.
>

Fixed.

>
>
> ---- Other ----
>
> Table of Contents
> "4.2.8 Extending the ApplicationCache interface" is a link, but its
> href is just "#" as that section does not have an id.
>

Fixed

Nikunj Mehta
http://blog.o-micron.com

Received on Monday, 4 January 2010 20:44:49 UTC