[Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Laszlo Papp]

On Sat, Feb 15, 2014 at 7:49 PM, Kurt Pattyn <pattyn.kurt at gmail.com> wrote:
>
> On 15 Feb 2014, at 20:38, Laszlo Papp <lpapp at kde.org> wrote:
>
>> I have not read this thread through, but it is long for me now, but I
>> would like to note one suggestion from my side:
>>
>> Make 1-2 unstable releases or a new add-on module. Unfortunately, we
>> have not done that, and we are now stuck with a couple of bad API
>> issues for a few years. This could have been avoided with 1-2 unstable
>> releases because the user feedback began to come once it had been
>> released and out.
> QtWebSockets currently is an add-on module.

My email is full of typos as usual. :-) (s/or a new add-on module/for
a new add on module/)

What I meant to write is add-on modules could have this qualifier for
their first 1-2 releases as part of Qt.

>> Such a disclaimer could be done as part of Qt 5.3, etc. I think it is
>> unpleasant for the end users, but if the communication is clear
>> between the developer(s) and end users why it is so, I think this will
>> serve good.
> Not a bad idea at all.
>>
>> That being sad, I may be totally wrong, and websockets has already
>> received a lot of end-user feedback with thorough API usage than
>> QtSerialPort when it was first released as part of Qt. In that case,
>> feel free to ignore me. I am just trying to help.
>
> Your help is definitely appreciated.
> QtWebSockets is a different beast than QtSerialPort I think.
> It is kind of a socket, and as such has been modelled after the well-established
> QAbstractSocket API. The server part is modelled after the well-established
> QTcpServer API. Besides that there are 2 RFCs: one describing the protocol
> itself and one describing the JavaScript API. So, we know what is to be
> expected from a web socket.

That is a nice thing and helps with ensuring the API quality. I am not
judging your work here, and I am actually impressed by the fact it has
many working examples, tests, etc, which we still do not have in
QtSerialPort. :)

IMHO, no matter how easy the situation is for an add-on, API mistakes
can always happen that are revealed by the end users. AFAIK, several
Qt classes had gone to public after thorough internal usage, so there
was the user feedback there internally.

I wish I could ask for the Delorean from the Dr. Emmett Brown, go
back, and do it this way. What we decided internally that for new
features (and API), we have 1-2 unstable releases for that part with
clear qualifier. Of course, if the Qt Project does not allow us to do
that, we will withdraw that idea instantly.