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
<[email protected] <mailto:[email protected]>> 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, [email protected]
<mailto:[email protected]> wrote:
*From:*Richard Gerd Kuesters <[email protected]
<mailto:[email protected]>>
*Subject:**Re: [Development] [Feature Request] Websockets*
*Date:*28 Aug 2013 19:28:11 GMT+02:00
*To:*[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
