[Development] Fwd: Qt 5.3 Feature freeze is coming quite soon...

[Hausmann Simon]

Given that there exists a web idl for Web sockets, I suggest the qml api to consist of a QML element and a Javascript constructor. The prototype and the qml element should probably have the same api, the web Standard one.

It is in our interest that third-part JS code out there using web sockets can be used seamlessly in qml.

Simon

Fra: Konstantin Ritt
Sendt: 14:44 lørdag 18. januar 2014
Til: Kurt Pattyn; development at qt-project.org
Emne: Re: [Development] Fwd: Qt 5.3 Feature freeze is coming quite soon...



2014/1/18 Kurt Pattyn <pattyn.kurt at gmail.com<mailto:pattyn.kurt at gmail.com>>




On 18 Jan 2014, at 01:18, Konstantin Ritt <ritt.ks at gmail.com<mailto:ritt.ks at gmail.com>> wrote:

After a brief review, I have a strong feeling that QWebSocket doesn't fit QtNetwork at all.

The main reason I see is that that QWebSocket isn't really a Q*Socket in  QtNetwork sense, it is actually a protocol.
And just to continue:
a) it doesn't derive from QAbstractSocket (and thus can not be treated as sequential IO device);
b) it doesn't support instantiation from the socket descriptor;
c) it's read/write methods are quite ambiguous (i.e. think about websocket->write("message or data, guess what"); ) - in my opinion, there must be no "const char*" overloads at all.
Right. These functions will be removed.

(Also note that WebSocket QML extension doesn't support data frames in it's API).
It seems that QML doesn't support binary buffers yet. That's the reason the binary dat functions have been left out from the QML module.


Right. Though QStrings isn't supported by QML, too :)
Everything goes through meta-type system, so it could be ::writeData(QVariant data) ->    socket.writeData('string-alike data'); socket. writeData(new Date(2014, 0, 18));  socket.writeData([ a, b, c, d ]);


 If it would make some usefulness to QNAM, QWebSocket could probably go to QtNetwork module (I'd prefer a better name then, anyways). Can not imagine QWebSocketServer in Qt itself.
Can you elaborate on this? Why do you think it is not a good name?


In QNAM, we have HTTP and FTP (both are protocols, too). We could probably have WebSocketProtocol support in QNAM as well (and maybe share it's private header(s) to QtWebSocket module). Not sure how useful it'll be for QNAM, though.


Regards,
Konstantin

+1 for add-on.


Regards,
Konstantin


2014/1/18 Kurt Pattyn <pattyn.kurt at gmail.com<mailto:pattyn.kurt at gmail.com>>
On 17 Jan 2014, at 21:01, Matt Broadstone <mbroadst at gmail.com<mailto:mbroadst at gmail.com>> wrote:

I'm inclined to agree with Rich, opting for keeping this as an addon.. for now. It's a 7k loc codebase that was mostly written in the past 1-3 months.
The code is actually older than the 3 months it is on the playground.

How much has it been tested in the real world? Do you have examples of people using it in production?
Well, this is one product: http://www.barco.com/en/products-solutions/software/medical-calibration-and-qa-software/automated-quality-assurance-of-medical-displays-in-private-practices.aspx/.
I received mails from people asking when this would be included in Qt, because they are hesitant to use a non-official module. It's a chicken-and-egg problem.
I know of 2 high-end products that are including this into their next release (cannot disclose now). I used it in several projects, one of which was a server delivering big DICOM files to browsers. Furthermore, I can imagine Enginio using it (Frederik or Jedrzej could you shed some light on this?).

It also seems like actual review of the module has just begun in this very email thread.
There were already quite some reviews. But now it got renewed attention. There is nothing fundamentally wrong with the code; here and there some minor adaptations, but nothing fundamental to the API. The QML component has been reviewed by Alan.


There's likelihood that the API is going to change (perhaps dramatically) based on actual usage, and you would be limiting your ability to make those changes by moving it into the core module.
The API is stable and has been reduced to its bare minimum. Some methods have been removed, because it is easier to add them then to remove them, if ever needed.


tl;dr: wouldn't it be better to maintain it as an add-on for now and let it mature a little bit, rather than rush to judgement for this release?
No rushing here. The feature list of 5.3 gets closed soon, so it's a good time to propose.
The problem with an add-on on the playground is the build system. Some people on Windows are complaining that they have to install Perl in order to compile. Others don't like compiling 3rd party modules and prefer binaries.
The code has been extensively tested with the Autobahn TestSuite and was tested with XCode Instruments for memory leaks. I am quite confident that the code is mature enough.
Besides that, there are requests in Jira asking for web socket functionality. So, at least 3 people would be made happy :-)

Cheers,
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/20140118/3edc117d/attachment.html>