On Jan 1, 2010, at 1:07 PM, Joseph Pecoraro wrote:
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.
This was clarified in the proposed WD.
- 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().
I like this idea. I have added the function to the MutableHttpResponse
interface
[1]: http://docs.jquery.com/QUnit
Nikunj Mehta
http://blog.o-micron.com
