- From: Joseph Pecoraro <joepeck02@gmail.com>
- Date: Fri, 1 Jan 2010 15:34:54 -0500
- To: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Cc: public-webapps@w3.org
> 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(); - 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' ---- 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. ---- 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; - 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'; - 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; ---- 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. Joseph Pecoraro
Received on Friday, 1 January 2010 20:35:24 UTC