RE: Network API editor's draft

Hi Charles,

I see only non-blocking communication in the draft. This is 
probably intentional, but adding the possibility for "blocking 
sockets" would provide more flexibility for the developer, and 
make some problems easier to solve.

This could be provided in different ways, f ex through a
connection instance method recv() that would block until data 
arrives on the specified connection.

When implementing any protocol containing a couple of 
handshaking layers it is convenient to be able to say "now I 
want to wait until at least four bytes arrives". Without the 
blocking feature you tend to end up with a maze of asynchronous 
handler functions or overly complex state-machines.

To avoid inventing yet another "synchronous XMLHttpRequest kills 
the window" scenario, the following could be considered:
- possible to specify timeout for how long to block
- handle ui events while blocking (so browser window is "alive")
- potentially let browser's stop button abort blocking

Also, blocking is your only chance if you want to send (and 
acknowledge) something at page exit, from inside the 
Window.onunload handler.

Best regards
Mike Wilson

> -----Original Message-----
> From: public-webapi-request@w3.org 
> [mailto:public-webapi-request@w3.org] On Behalf Of Charles 
> McCathieNevile
> Sent: den 7 mars 2007 08:27
> To: web API
> Subject: Network API editor's draft
> 
> 
> Hi folks.
> 
> Thanks to Gorm and the WHATWG, we have 
> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/ne
twork-api.html
> 
> Comments and brickbats welcome
> 
> cheers
> 
> Chaals
> 
> -- 
>   Charles McCathieNevile, Opera Software: Standards Group
>   hablo español  -  je parle français  -  jeg lærer norsk
> chaals@opera.com          Try Opera 9.1     http://opera.com
> 
>

Received on Wednesday, 7 March 2007 22:29:29 UTC