W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [DataCache] Unhandled Cases in Networking Changes

From: Joseph Pecoraro <joepeck02@gmail.com>
Date: Fri, 1 Jan 2010 16:07:25 -0500
Cc: public-webapps@w3.org
Message-Id: <40B85FF2-44C4-44D8-BD5D-819CD5AF8EC6@gmail.com>
To: Nikunj R. Mehta <nikunj.mehta@oracle.com>
>> There is nothing specified for what to do when there is no embedded server for the resource. [...]
> 
> In case no embedded server is available, the user agent fetches from the server. I have clarified this in the spec. This behavior makes most sense.

Thanks for clarifying.


>> 2. In the off-line case there is a MutableHttpResponse that gets written to by the interception function. Here is one of the sub-steps:
>> 
>> [[
>> 10.4 Wait for the interception function to dispatch the dynamic response.
>> ]]
>> 
>> I think this is ambiguous. When does the interception function "dispatch" the response?
>> 
>> - it can explicitly dispatch by calling MutableHttpResponse.send;
>> http://dev.w3.org/2006/webapi/DataCache/#response-send
> 
> This is the correct way.
> 
>> However what happens if send() is not called? What happens when:
>> 
>> - the interception function exits (either by exception or naturally)
> 
> The normal network timeout logic should apply here.

Ahh, I see. I had not thought about that. Thanks.

In that case, the wording "Wait for the ..." could be interpreted
as waiting unconditionally. Maybe that could be clarified. I see
many developers getting caught forgetting send() and getting
weird, unexpected errors / behavior across different implementations.


>> - implicitly dispatch
>> - raise an exception and abort to normal behavior
>> 
>> I am currently siding with implicitly dispatching, which makes the send() optional (and unnecessary?). Do you see any disadvantage to this?
> 
> Implicitly dispatching is a problem since the interception function may have to wait until a time some storage operation completes.

Good point. I thought of that later, and I agree. I guess I am
more used to how an Async-capable JavaScript testing library
QUnit [1] handles this. Its implicit by default, but if you
want it to be explicit, you can.

The workflow would then be:

  response.delay(); // explicitly saying, wait for the send()
  // trigger async action
  setTimeout(function() {
    // do work...
    response.send();
  }, ...);

I just bring that up for discussion purposes. I am fine with
always explicitly calling send().

[1]: http://docs.jquery.com/QUnit


Joseph Pecoraro
Received on Friday, 1 January 2010 21:08:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT