Re: [hybi] Straw poll: Do you miss interjectable WebSocket level control frame? (was: Re: Discontinuation of mux ...)

[Ian Hickson <[e-mail]>]

On Fri, 28 Feb 2014, Zhong Yu wrote:
> 
> I think this is a good choice for most use cases. But eventually someone 
> will need the feature of abort/cancel an outgoing message that takes too 
> long to transmit.

Once someone has a use case for this, we can study it and consider the 
right solution.


> If write() is a blocking method, it makes sense that close() after 
> write() should flush the data at best effort. But here write() is a 
> non-blocking, async method, it's not intuitively clear what should 
> happen if close() is called when a write action is still ongoing.

In the Web Socket API, WebSocket.send() and WebSocket.close() are both 
specced as atomic. The fact that buffering has to happen is an 
implementation detail (albeit one exposed in the bufferedAmount 
attribute). The protocol spec could provide more detailed hooks to control 
this, of course. But I don't think the specs are unclear.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'