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

[Philipp Serafin <[e-mail]>]

Am 06.09.2011 17:54, schrieb Tobias Oberstein:
> 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-based *and* frame-based APIs?

Frames may be arbitrary buffered by intermediaries, the current
javascript API hides frames completely and, as previously discussed, you
can't be sure 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. What additional benefits compared to a
message-based API would that give you?