[Development] Development Digest, Vol 23, Issue 123

[Richard Gerd Kuesters]

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 [3] wrote: 
> 
>> FROM: Richard Gerd
Kuesters <richard at humantech.com.br [1]>
>> 
>> SUBJECT: RE:
[DEVELOPMENT] [FEATURE REQUEST] WEBSOCKETS
>> 
>> DATE: 28 Aug 2013
19:28:11 GMT+02:00
>> 
>> TO: development at qt-project.org [2]
>> 
>> 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
> 
>> 
 

Links:
------
[1] mailto:richard at humantech.com.br
[2]
mailto:development at qt-project.org
[3]
mailto:development-request at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130828/b2331133/attachment.html>