- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Mon, 4 Jan 2010 14:49:37 -0800
- To: Joseph Pecoraro <joepeck02@gmail.com>
- Cc: public-webapps@w3.org
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
Received on Monday, 4 January 2010 22:52:21 UTC