On Sat, Feb 15, 2014 at 7:49 PM, Kurt Pattyn <[email protected]> wrote: > > On 15 Feb 2014, at 20:38, Laszlo Papp <[email protected]> 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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
