- From: Joseph Pecoraro <joepeck02@gmail.com>
- Date: Fri, 1 Jan 2010 16:07:25 -0500
- To: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Cc: public-webapps@w3.org
>> 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 UTC