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

Re: [DataCache] Unhandled Cases in Networking Changes

From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
Date: Mon, 4 Jan 2010 14:49:37 -0800
Cc: public-webapps@w3.org
Message-Id: <6D6364F8-F886-4534-9450-90ED8306A910@oracle.com>
To: Joseph Pecoraro <joepeck02@gmail.com>

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 GMT

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