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

Richard Moore rich at kde.org
Fri Jan 17 12:26:57 CET 2014


Resend from the right email address.

---------- Forwarded message ----------
From: Richard Moore <richmoore44 at gmail.com>
Date: 17 January 2014 11:25
Subject: Re: [Development] Qt 5.3 Feature freeze is coming quite soon...
To: Knoll Lars <Lars.Knoll at digia.com>
Cc: Steve Gold <steveg2357 at gmail.com>, Kurt Pattyn
<pattyn.kurt at gmail.com>, "development at qt-project.org"
<development at qt-project.org>, Heikkinen Jani
<Jani.Heikkinen at digia.com>, "releasing at qt-project.org"
<releasing at qt-project.org>, Thiago Macieira
<thiago.macieira at intel.com>, Peter Hartmann <phartmann at blackberry.com>


On 17 January 2014 07:54, Knoll Lars <Lars.Knoll at digia.com> wrote:
>
> From a feature point of view it would fit best into Qt Network. But it's a sizeable piece of code added to Qt Network. Do you have any numbers on how this changes the size of Qt Network?
>
> Peter and Rich, and comments from your side?
>

Given that the websocket code contains both C++ networking stuff and
also QML it cannot all go into qt network as this would introduce a
circular dependency on the qtdeclarative module. This would mean
splitting it into two one part in qt network and another in qt
declarative which I think would be a bit confusing for users.

On the other hand as an addon module the dependency problem is gone
and it can be available as a single self-contained module (with
unified documentation) which I suspect would be easier on those using
the module. I don't think adding QT += websockets to the pro file
would be a barrier for adoption.

Given the above (and ignoring the issue of code-size etc.) my initial
feeling is that an addon module is probably a better choice for users
of the module.

Cheers

Rich.



More information about the Development mailing list