- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Mon, 4 Jan 2010 12:43:36 -0800
- To: Joseph Pecoraro <joepeck02@gmail.com>
- Cc: public-webapps@w3.org
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