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

[Zhong Yu <[e-mail]>]

On Wed, Feb 26, 2014 at 11:35 AM, Ian Hickson <[e-mail]> wrote:
> On Wed, 26 Feb 2014, Takeshi Yoshino wrote:
>>
>> I think it's underspecified. In the WHATWG WebSocket API spec, close()
>> is required to "start the WebSocket closing handshake". RFC 6455 neither
>> says the algorithm may terminate ongoing "Send a WebSocket Message"
>> algorithm nor says it may not.
>
> If it doesn't allow it, then it's not allowed.
>
> If you send a bunch of messages, then start the closing handshake, then
> the messages should all be sent.

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.

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.

Zhong Yu


> I don't think there's anything in either
> spec that would allow the handshake to jump ahead.


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