On 27 Oct 2013, at 12:00, [email protected] wrote:
> From: Thiago Macieira <[email protected]>
> Subject: Re: [Development] QtWebSockets: API advice #2
> Date: 27 Oct 2013 11:36:40 GMT+1
> To: [email protected]
>
>
> On domingo, 27 de outubro de 2013 11:16:03, Kurt Pattyn wrote:
>> currently the QWebSocket class (see
>> https://qt.gitorious.org/qtplayground/websockets), emits the signals
>> textFrameReceived() and binaryFrameReceived(). These signals are tightly
>> connected with the way web sockets work. Too me, this feels too ‘low
>> level’. Wouldn’t it be better to buffer these frames, and provide a
>> QIODevice-like streaming interface? Whenever a frame arrives, it is stored,
>> and the signal readyRead() is emitted.
>>
>> What are your thoughts?
>
> You tell us how web sockets are meant to be used. Are you supposed to read a
> stream off a web socket?
If we consider the JavaScript WebSockets API, then there is no streaming API.
But, the WebSocket protocol can perfectly support this, as data is sent in
chunks.
I mainly asked the question to see what the best fit would be with the rest of
the Qt framework (QTcpSockets, QNetworkAccessManager, …).
The implementation can still go all the way, but I’d prefer to keep it as
aligned as possible to existing Qt APIs.
>
> How about multiple streams? HTTP/2.0 supports multiple streams.
Multiple streams are not part of the WebSockets protocol, but can be
implemented on top of it. HTTP 2.0 can be run over WebSockets for example.
An alternate HTTP 2.0 draft proposal (httpbis-speed-mobility) actually uses
WebSockets for the transport layer and adds the SPDY multiplexing and HTTP
mapping as an WebSocket extension (WebSocket extensions are negotiated during
the handshake).
So, WebSockets is more comparable to TCP than it is to HTTP.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
