[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