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

[Konstantin Ritt]

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. (Also note that WebSocket QML
extension doesn't support data frames in it's API).

 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.
+1 for add-on.


Regards,
Konstantin


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

> On 17 Jan 2014, at 21:01, Matt Broadstone <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
> 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/05447f25/attachment.html>