[Development] Development Digest, Vol 23, Issue 123

Richard Gerd Kuesters richard at humantech.com.br
Mon Sep 9 20:01:08 CEST 2013


Thanks Shane! I'm aware of the workaround, I just didn't know that 
Webkit's WS implementation was not bound to the QNetworkAccessManager. 
With a little source code reading, I think it would not be possible to 
manage network connection from an unique entry point to all my Qt based 
apps. I'll have to address it any other way :)

Best regards,
Richard.

On 09/09/2013 02:45 PM, Shane Kearns wrote:
> If you wanted to access a websocket service from native c++ or from 
> QML javascript, it would be quite hard to use webkit's implementation.
> I expect you'd have to invoke some javascript inside the webkit engine 
> to do the request for you and get a result.
>
> Websocket is an unpleasant workaround to the current state where many 
> users can only make outbound connections on TCP port 443, which 
> prevents the TCP ports being used as intended for multiplexing.
>
>
> On 29 August 2013 00:51, Richard Gerd Kuesters 
> <richard at humantech.com.br <mailto:richard at humantech.com.br>> wrote:
>
>     Thanks Kurt :)
>
>     I've got some time today reading Qt 5.1.1 (and its Webkit) source
>     code. What I found was a big mess :)
>
>     I understand now that your implementation is valid, and I think it
>     should continue as is until further notice. Unfortunately, there
>     is already a websocket client implementation in Qt source code, in
>     Webkit, provided by Google. I made some tests today and any call
>     on Webkit using "wss*:\/\/" is not available to QNetwork, and ...
>     Man, it would be a very, very huge effort to do it "in a flash".
>     Even the most experienced C++ programmer wouldn't do it overnight,
>     as you said.
>
>     That brought me, otherwise, to the ultimate question: is the Qt
>     community ready to start thinking about ripping this off the
>     Webkit's webcore? If so, I'll be glad to help, somehow. // FYK, I
>     just realized how intense your work was today, about 5 PM (local
>     time), when I realized how much the Webkit code is a mess. A real,
>     *real* mess; and I think that's why Shane (and other users) think
>     your work must not stop. Now, it includes me :)
>
>     Sorry if I made my assumptions just on top of Webkit, it is simply
>     the module I use the most. I thought Qt was a little more uniform
>     (assuming what they are requiring from you to make your websocket
>     implementation initially an addon). I was terribly wrong :)
>
>     Keep up your good work, I'm glad someone is carrying this with
>     such enthusiasm!! :)
>
>     My best regards,
>
>     Richard.
>
>     Em 2013-08-28 19:46, Kurt Pattyn escreveu:
>
>>
>>     On 29 Aug 2013, at 00:21, development-request at qt-project.org
>>     <mailto:development-request at qt-project.org> wrote:
>>
>>>     *From:*Richard Gerd Kuesters <richard at humantech.com.br
>>>     <mailto:richard at humantech.com.br>>
>>>     *Subject:**Re: [Development] [Feature Request] Websockets*
>>>     *Date:*28 Aug 2013 19:28:11 GMT+02:00
>>>     *To:*development at qt-project.org <mailto:development at qt-project.org>
>>>
>>>     A couple of things got me thinking about the WebSocket
>>>     implementation:
>>>
>>>     2. I believe that a websocket client would be directly attached
>>>     to this network behaviour; it makes no sense to have a
>>>     "headless" websocket in Qt - why not use a conventional socket?
>>>     I think it might be useful, but just in some special cases.
>>>     Other thing is: as I was looking into webkit source code, it
>>>     already has a websocket client implementation. That brings
>>>     another question: why is it there, after all? Why not in the
>>>     network core?
>>     Hi Richard, this subject has been touched by Shane already.
>>     Indeed, you are right that this should be integrated into the
>>     QtNetwork module. But, a web socket is not just a socket, it is a
>>     tcp socket that is upgraded, after a handshake to a web socket.
>>     According to Shane, it is not that easy to integrate this into
>>     the current code.
>>     It has been decided, to put this code into the playground, so that
>>     1. it at least integrates nicely with the Qt infrastructure
>>     2. it is thoroughly reviewed and tested
>>     3. we can wait and see what the demand is for this
>>     I can understand that turning the network module upside down to
>>     add some feature, is not something that is done overnight.
>>     Eventually, it can become an add-on or an integral part of the
>>     network module.
>>
>>>     3. About the websocket server: it is, in fact, a new
>>>     implementation for Qt.
>>     Yes, it is. Depending on how 'high' Qt wants to evolve, I don't
>>     see a reason why it wouldn't fit. Personally, I see it as an
>>     opportunity, especially for embedded devices that are more and
>>     more controlled via web browsers (at least, that is what I am
>>     using it for). Having a web socket server in there, could
>>     dramatically enhance the possibilities (monitoring,
>>     notifications, aso). But then there is of course node.js also.
>>>
>>>     I'm not trying to be a pain in the a**, just the devil's
>>>     advocate, random thoughts on the direction this intend to go.
>>     It doesn't hurt. Discussion is sane, and questions are for free.
>>     Kurt
>
>     _______________________________________________
>     Development mailing list
>     Development at qt-project.org <mailto:Development at qt-project.org>
>     http://lists.qt-project.org/mailman/listinfo/development
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130909/6191c0e4/attachment.html>


More information about the Development mailing list