- From: Joseph Pecoraro <joepeck02@gmail.com>
- Date: Mon, 4 Jan 2010 16:26:29 -0500
- To: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Cc: public-webapps@w3.org
>> - 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). I meant "multiple clients" more broadly. Such as multiple users, on different machines. > Secondly, reviewing a GET response is easy to do with the oncapture event handler that is defined on transactions. Again, why the special case? Why not just naturally include GET in the reviewable requests. I realize that the oncapture event will only fire with GET requests, but I don't see any advantage to separating it out completely. > 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. I agree, I have no complaints here about offlinehandlers. However, "if an application wishes to review" why should it need to "use the [[captured]] events for examining data returned from a GET" instead of just using the review handler it already set up? >> - IDL Descriptions >> HttpRequest#bodyText and HttpResponse#bodyText >> >> [.. snip ..] >> >> 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 Excellent, this is much better. Thanks. I have no experience in Specification writing. Is there some way, like you have done with the HTML5 terminology, to point out that this section refers / should be kept in sync with the XHR description; to prevent one or the other getting out of date? >> - 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. It sounds like the reason these methods exist are to manipulate the otherwise readonly pendingUpdates attribute of ApplicationCache2 to "provide some idea [...] as to how large the dirty data has become". If that is the case, then it would be useful to have a number value that is persistent that you can easily adjust. I have a feeling that changes by 1 may be overly restrictive, but I will wait for usage feedback. It may be that increment / decrement operations work very nicely with the rest of the API. Thanks for the clarifications and fixes for the other issues. - Joseph Pecoraro
Received on Monday, 4 January 2010 21:27:01 UTC