Re: [hybi] Changing meaning of 1007 status code ("frame" => "message")

[Tobias Oberstein <[e-mail]>]

> > No, thats not WS. WS itself is not a message based, but framed
> > streaming protocol.
> >> - The WS transport layer receives control frames and send control
> >> frames to the other endpoint.
> >> - The WS transport layer gives received *messages* to the WS
> >> application layer (it doesn't matter giving the full buffered message or
> using straming).
> > No, I have 3 types of API: message-based, frame-based and streaming.
> I can understand the rationale for a streaming-based API (though I don't see
> why already established multimedia protocols like SIP, RTSP or RTMP
> wouldn't be a better choice here) but why would we both need message-

None of these has the (promised) attraction of being "compatible with
restricted network infrastructures".

> based *and* frame-based APIs?

A multimedia application that wants to stream over WS may want to control
fragmentation size when sending. Intermediaries MAY coalesce/fragment,
but only when not extension is in place, which semantics is not understood
by the interm.
 
> Frames may be arbitrary buffered by intermediaries, the current javascript
> API hides frames completely and, as previously discussed, you can't be sure

The JS API is just that: an API for a single environment in which WS is
implemented.

Other environment may provide frame-based/streaming APIs, and even
JS may provide such things in a 2nd revision.
 
> that a frame belonging to a text message actually contains valid UTF-8. All of
> that seem to make them a decidedly bad choice for me to base your API on.

Of course a frame-based API may be more useful for binary messages. But
even for text: what if I write received streams immediately to a temp file.
When the connection fails because of invalid UTF-8, I just delete the temp file.
When everythings fine till the message end, I rename the temp file to final file.

> What additional benefits compared to a message-based API would that give
> you?

As a library author, I want to give choice to users, since I don't know their
requirements.
I would not use a mixture of APIs in _one_ application.