Re: [DataCache] Updated Examples

> 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