On Jan 1, 2010, at 12:34 PM, Joseph Pecoraro wrote:
I have updated the examples with the new API. Please let me know if
you see any issues now. Thanks a lot for the detailed feedback.
Sure, these all deal with section 4.1.1 Examples in new
January 1, 2010 Editors Draft:
http://dev.w3.org/2006/webapi/DataCache/#examples
---- Old Issues ----
- setting data on the Mutable response should use the methods defined
in the IDL, and not the properties (which I assume are readonly).
setting the statusCode and statusLine on the should use
MutableHttpResponse#setStatus
http://dev.w3.org/2006/webapi/DataCache/#widl-MutableHttpResponse-setStatus
setting bodyText should use MutableHttpResponse#setResponseHeader
http://dev.w3.org/2006/webapi/DataCache/#widl-MutableHttpResponse-setResponseText
setting headers should use MutableHttpResponse#setResponseHeader
http://dev.w3.org/2006/webapi/DataCache/#widl-MutableHttpResponse-setResponseHeader
Something like the following from the previous email:
response.setStatus(200, 'HTTP/1.1 200 OK');
response.setResponseText(request.bodyText);
response.setResponseHeader('Content-Type', ...);
response.send();
Done
- if you still intend statusLine to be the full HTTP status line, I
would
suggestion changing the current version to more standard values:
(NOTE: These appear in multiple examples)
'HTTP/1.1 OK' => 'HTTP/1.1 200 OK'
'HTTP/1.1 Bad Request' => 'HTTP/1.1 400 Bad Request'
Changed
---- New Issues ----
- The second example has:
[[
window.navigator.registerOfflineHandler(uri, local);
]]
However, the specification for registerOfflineHandler claims the
third
parameter to registerOfflineHandler is not optional:
http://dev.w3.org/2006/webapi/DataCache/#widl-NavigatorLocalServer-registerOfflineHandler
My Suggestion:
Make the review handler optional. Since you may not always want
to use
a reviewer. Forcing it (like Firefox enforces the 3rd parameter on
addEventListener) can cause developer headaches.
The reviewer function is now optional in the API and networking model.
It already was in the conceptual model.
---- Nit Picking ----
- I suggested using "var cache" in the last example, for good
practice
(even though the code looks like it is in the global scope):
[[
cache = window.applicationCache;
]]
Would become:
var cache = window.applicationCache;
Done.
- A variable "type" appears out of nowhere. It would be nice to
clarify:
[[
response.headers['Content-Type'] = type;
]]
Could become a number of options. For instance:
response.headers['Content-Type'] = request.headers['Content-
Type'] || 'text/plain';
Done.
- There is a line without a semicolon. For consistancy it would be
nice:
[[
var txn = cache.request.result
]]
Would become:
var txn = cache.request.result;
Done
---- Questions ----
- It would be nice to see examples of:
- CacheTransactionRequest#incrementPendingUpdates and decrement
I am interested to know why they are useful.
http://dev.w3.org/2006/webapi/DataCache/#widl-CacheTransactionRequest-incrementPendingUpdates
http://dev.w3.org/2006/webapi/DataCache/#widl-CacheTransactionRequest-decrementPendingUpdates
- ApplicationCache2Request-openModifiedItemCursor
This seems like an important concept for synchronization!
http://dev.w3.org/2006/webapi/DataCache/#widl-ApplicationCache2Request-openModifiedItemCursor
- Registering an event listener, for one of the CacheEvent's.
This would clarify Cache Host registration.
I will leave this for a future WD.
Nikunj Mehta
http://blog.o-micron.com
