[Development] [Feature Request] Websockets (Christian Gagneraud)

[achartier at fastmail.fm]

I am also greatly interested in seeing this websockets functionality
integrated into Qt (preferably into the main codebase and not as an
add-on). I have been waiting for this functionality for about a year
now, but hadn't seen much activity aside from the QtWebSockets project.

Also, if it's not already planned, it would be most helpful if the Qt
websocket socket class derived from QIODevice either directly or
indirectly so it could be treated similarly to QLocalSocket and
QTcpSocket.

Thank you for the effort Kurt! Looking forward to seeing this merged
into Qt. :)

On Wed, Aug 14, 2013, at 08:44 PM, development-request at qt-project.org
wrote:
> Send Development mailing list submissions to
> 	development at qt-project.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.qt-project.org/mailman/listinfo/development
> or, via email, send a message with subject or body 'help' to
> 	development-request at qt-project.org
> 
> You can reach the person managing the list at
> 	development-owner at qt-project.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Development digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: [Feature Request] Websockets (Thiago Macieira)
>    2. Re: [Feature Request] Websockets (liuyanghejerry)
>    3. Re: [Feature Request] Websockets (Christian Gagneraud)
>    4. Re: QTBUG-30440: restricting the SIMD files (Christian Gagneraud)
>    5. operators as members or not (Glen Mabey)
>    6. Re: 5.1 sound (Laszlo Papp)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 14 Aug 2013 17:40:36 -0700
> From: Thiago Macieira <thiago.macieira at intel.com>
> Subject: Re: [Development] [Feature Request] Websockets
> To: development at qt-project.org
> Message-ID: <2476539.zlEZN8K7uj at tjmaciei-mobl2>
> Content-Type: text/plain; charset="us-ascii"
> 
> On quinta-feira, 15 de agosto de 2013 02:20:34, Kurt Pattyn wrote:
> > BTW: I only received 2 responses to this mail: does that mean, this is not
> > important enough to be considered for inclusion? I am a bit confused about
> > how to proceed. Do I just dump the code into gitorious, and wait for
> > reactions? Do I leave it where it is? (BTW, Shane already reviewed some of
> > the code, which is awesome; thanks Shane).
> 
> That means you received 3 separate feedbacks, not counting the IRC
> discussion 
> I saw you were in, in less than 12 hours since your post.
> 
> I qualify that as "people quite interested".
> 
> Particularly for me, I was waiting for Peter and Shane's reactions. And
> I've 
> been busy.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 190 bytes
> Desc: This is a digitally signed message part.
> Url :
> http://lists.qt-project.org/pipermail/development/attachments/20130814/a3d8dc10/attachment-0001.bin 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 15 Aug 2013 09:09:03 +0800
> From: liuyanghejerry <liuyanghejerry at 126.com>
> Subject: Re: [Development] [Feature Request] Websockets
> To: development at qt-project.org
> Message-ID: <520C2A2F.3040300 at 126.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Well, I'm interested in websocket. Since websocket has been one of the 
> most popular protocols among internet, espcially in real-time based 
> websites. It's good to see it in Qt, no matter as add-on or directly in 
> the source.
> 
> But in my own opinion, add-on may loss support during version bump of 
> Qt. Last time I checked around add-ons, there were still some of them 
> remain in 4.8.
> 
> BTW, there's another implementation of websocket in Qt[1], I have no 
> idea what's the difference of yours and this one.
> 
> [1]:https://gitorious.org/qtwebsocket 
> <https://gitorious.org/qtwebsocket#more>
> 
> 
> ? 2013/8/15 8:20, Kurt Pattyn ??:
> > Hi Peter,
> >
> >
> >
> > On 14 Aug 2013, at 18:32, Peter Hartmann <phartmann at blackberry.com> wrote:
> >
> >> Hello,
> >>
> >> thanks for the effort!
> >>
> >> On 08/14/2013 05:54 PM, Kurt Pattyn wrote:
> >>> (...)
> >>> 1. Is there any interest in adding this to Qt?
> >> yes, please :)
> >>
> >>> 2. If so, should this be added to QtNetwork or is a add-on preferred?
> >> My first impression is that it is not extensively used by big sites (yet), is it? So I would rather go for an add-on for now, but I am of course open to be convinced otherwise.
> >>
> > I don't have figures about the popularity of websockets, so I cannot tell. Going for an add-on seems acceptable, given the large install base of Qt.
> >
> >> Also apparently the API is rather big (5 classes with lots of methods), so adding it as an add-on (first) might be something to consider as well, in case we want to change the API even after the review or so...
> > Well, the API for the end-user consists in fact only of 2 classes: one for client applications (WebSocket class, comparable to QTcpSocket), and one for server applications (WebSocketServer class). The APIs are modelled after QAbstractSocket resp. QTcpServer, so the learning curve should be minimal.
> > However, you have a point that it might be better to add it to the add-ons, in order to get a 'feeling' if it fits the main library or not (I suppose customers will tell).
> >
> > BTW: I only received 2 responses to this mail: does that mean, this is not important enough to be considered for inclusion? I am a bit confused about how to proceed. Do I just dump the code into gitorious, and wait for reactions? Do I leave it where it is? (BTW, Shane already reviewed some of the code, which is awesome; thanks Shane).
> >
> > Kurt
> >
> >> Peter
> >>
> >>
> >>> Best regards,
> >>>
> >>> Kurt Pattyn
> >>> _______________________________________________
> >>> Development mailing list
> >>> Development at qt-project.org
> >>> http://lists.qt-project.org/mailman/listinfo/development
> >>
> >> ---------------------------------------------------------------------
> >> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
> > _______________________________________________
> > 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/20130815/a61c68ad/attachment-0001.html 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 15 Aug 2013 14:01:26 +1200
> From: Christian Gagneraud <chgans at gna.org>
> Subject: Re: [Development] [Feature Request] Websockets
> To: development at qt-project.org
> Message-ID: <520C3676.8060900 at gna.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 15/08/13 12:40, Thiago Macieira wrote:
> > On quinta-feira, 15 de agosto de 2013 02:20:34, Kurt Pattyn wrote:
> >> BTW: I only received 2 responses to this mail: does that mean, this is not
> >> important enough to be considered for inclusion? I am a bit confused about
> >> how to proceed. Do I just dump the code into gitorious, and wait for
> >> reactions? Do I leave it where it is? (BTW, Shane already reviewed some of
> >> the code, which is awesome; thanks Shane).
> >
> > That means you received 3 separate feedbacks, not counting the IRC discussion
> > I saw you were in, in less than 12 hours since your post.
> >
> > I qualify that as "people quite interested".
> 
> I am interested too! ;)
> 
> I had a look at your project a month ago (or so), and I would like to 
> use it with QtPlayground/QtJsonStream in a coming project.
> Basically My use case is a JSON based protocol that could go through a 
> QIODevice (especially QSerialPort, QTcpSocket and QWebSocket), that 
> would be awesome!
> 
> Chris
> 
> >
> > Particularly for me, I was waiting for Peter and Shane's reactions. And I've
> > been busy.
> >
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Thu, 15 Aug 2013 14:20:31 +1200
> From: Christian Gagneraud <chgans at gna.org>
> Subject: Re: [Development] QTBUG-30440: restricting the SIMD files
> To: development at qt-project.org
> Message-ID: <520C3AEF.3050604 at gna.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 15/08/13 10:23, Thiago Macieira wrote:
> > Hello all
> >
> 
> Hi Thiago,
> 
> > I've been running through this problem for a while. I might have finally a
> > solution, but I'd like to see if there are other options and which of the
> > solutions we should go for.
> >
> > == Quick medium-sized summary of the problem:
> >
> > 	https://bugreports.qt-project.org/browse/QTBUG-30440
> >
> > Qt has had a few source files that have been built with extra CPU requirements
> > for a few years now. The idea is that we can do better if we detect, at run-
> > time, that the CPU supports some extra features. So far, this has been
> > restricted to gui/painting/qdrawhelper* and gui/image/qimage* and the CPU
> > features we've used are ARM Neon, x86 SSE2, SSSE3, and AVX, MIPS DSP.
> >
> > This has been working for a few years, but it turns out that it has always
> > been a ticking time-bomb.
> >
> > Whenever any of those source files uses an inline function, the compiler must
> > choose between inlining or not. If it does *not* inline (such as in a debug
> > build), then the compiler emits the out-of-line copy of the full function and
> > the linker must merge all of those copies into one single copy. The linker
> > does that by choosing any of the copies. It may choose the wrong copy.
> >
> > == Example from the bug report:
> >
> > In the ARM build, qdrawhelper_neon.cpp makes use of qRound (an inline
> > function). That means qdrawhelper_neon.o in a debug build will have the
> > _Z6qRoundf symbol, but so will some 40 other .o files. All of them have the
> > same attributes: "hidden" visibility, "weak" binding.
> >
> > When the linker sees multiple "weak" symbols, it chooses one of them. I
> > believe it chose the first one listed in the command-line, which happened to be
> > qdrawhelper_neon.o.
> >
> > That means *all* calls to qRound(float) in QtGui would use the Neon version of
> > qRound, for which this particular compiler decided to use Neon instructions
> > (disassembly in [1]).
> >
> > == Possible solutions:
> >
> > 1) Drop simd.prf and the runtime checking
> >
> > This means dropping the special builds. We'd #include the special files if the
> > user is building Qt for a special target.
> 
> Can't you get rid of these special files, and build the whole Qt with 
> the same flags? Either "generic" flags or "optimised" flags.
> 
> >
> > Most drastic solution. It solves the problem at the expense of having faster
> > code paths for when the CPUs have it. For embedded devices, it might be
> > acceptable to have specially built Qt versions, but I don't think this flies
> > anymore even for Android.
> 
> Could you give a bit more details about the Android case? Is it related 
> with the fact that Android apps have to be somehow SoC agnostic?
> 
> >
> > What's more, on x86, the default 32-bit build is just nonsense today. CPUs
> > from the past 10 years from both Intel and AMD have had support for SSE2.
> 
> I've seen recently that now gcc have an option for this kind of 
> auto-optimisation, can't find any source, but basically gcc 
> automatically select CPU extension by looking at the CPU it is running 
> on. I saw that in a x86/SSE* context.
> 
> >
> > 2) Drop simd.prf, but keep specialised code and runtime checking
> >
> > This is a variant of #1. For compilers that support it, we'd #include the
> > special files unconditionally and call the specialised code after runtime
> > detection is performed.
> >
> > This assumes that the problem we have with the linker doesn't happen if the
> > special builds are present in the same translation unit.
> >
> > This is for sure possible with ICC, MSVC and GCC 4.9. It is not possible with
> > current versions of Clang or GCC.
> >
> > 3) Restrict any CPU-specific code to assembly files
> >
> > This is what the MIPS DSP solution is doing (MIPS isn't affected by this
> > problem).
> >
> > Drawbacks:
> > * requires writing assembly by hand
> > * requires at least two copies of all routines (one in GNU as sources, one for
> >    MS assembler)
> > * cannot benefit from compiler optimisations analyses
> > * qmake isn't very smart about assembly sources
> >
> > 4) Restrict any CPU-specific code to C or C++ source files with limited #include
> >
> > This is the solution I prefer (suggested by Shane on IRC). We'd keep the
> > special compilers, but we'd drop all the include paths for Qt headers. Those
> > sources would be restricted to system headers, which include the support for
> > intrinsics.
> 
> Does that mean that the ticking time-bomb will still be there somehow?
> I didn't understand all the low-levels details, this is certainly why 
> solution #1 sounds way more simple to me. The assembler code doesn't 
> look weird for the electronic engineer I am, it is still legion in the 
> wild, and the "technology" selection is made at run time, this is maybe 
> what would be nice to have for Android (If I understood the android case 
> correctly)
> 
> >
> > For C++ sources, we need to ensure no Standard Library headers are included
> > (same problem as Qt headers). ISO C headers are fine, since C89 doesn't support
> > inlines, and C99 inlines are just plain weird. Most C headers use "static
> > inline" for inlines, which is fine.
> >
> > For that reason, I think we should stick to C, unless there's a very good
> > reason why not (like GCC's dispatch feature, which is only supported in C++).
> >
> >
> > Suggestions?
> 
> Not really, but maybe a feature request:
> 
> Would it be possible to turn off any optimisation in the Qt build system 
> and let the distro/tools people select the optimum (cross) gcc flags for 
> their target (an ARM SoC in my case) *without* having to heavily patch
> Qt.
> Basically the build flags are controlled *only* by a specialised mkspec, 
> and there's no *_neon.cpp stuff in Qt.
> I'm not saying Qt build system performs badly in this regard, I'm just 
> saying that it is not unusual to "heavily" patch Qt to manage CPU/GPU 
> optimisations and cross-compilation issues.
> 
> My 2 cents.
> Chris
> 
> 
> >
> >
> > [1] https://bugreports.qt-project.org/browse/QTBUG-30440?focusedCommentId=200686&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-200686
> >
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Thu, 15 Aug 2013 03:11:20 +0000
> From: Glen Mabey <glen.mabey at swri.org>
> Subject: [Development] operators as members or not
> To: "development at qt-project.org" <development at qt-project.org>
> Cc: Thiago Macieira <thiago.macieira at intel.com>
> Message-ID:
> 	<D319E7E53A04264CACBD881401B335ED2A937B at swri16exbe1.electro.swri.edu>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hello,
> 
> I'm working on a couple of new classes and I wonder whether there is a
> policy (written or otherwise) on whether operators should be members or
> not.
> 
> In particular, this question has come up in 
>   https://codereview.qt-project.org/#change,59605
> and
>   https://codereview.qt-project.org/#change,60792 
> 
> I am no C++ philosopher, but I understand that some authorities (like
> stackoverflow) have their reasons for asserting that operators should not
> be members -- they also cite some sources.
>   http://stackoverflow.com/questions/4421706/operator-overloading/4421729#4421729 
> 
> Looks like Oliver Goffart did also weigh in on the issue, in 60792.
> 
> Is it possible that the Coding Conventions could be amended to indicate
> which way this issue should go, if only for new classes?
> 
> Thanks!
> Glen Mabey
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Thu, 15 Aug 2013 04:44:18 +0100
> From: Laszlo Papp <lpapp at kde.org>
> Subject: Re: [Development] 5.1 sound
> To: "Randolph D." <rdohm321 at gmail.com>
> Cc: "development at qt-project.org" <development at qt-project.org>
> Message-ID:
> 	<CAOMwXhOr4Bt-rm_hun1wt0jyeaFnCg2GeW0ZdGEwVAszm3MzDg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Please report on https://bugreports.qt-project.org if you had found a
> regression with proper information.
> 
> 
> On Wed, Aug 14, 2013 at 8:12 PM, Randolph D. <rdohm321 at gmail.com> wrote:
> 
> > I tried to work with sound.
> > that would be the nogo for a upgrade to 5.1
> > can someone please fix the sound working qith a qrc file?
> >
> > thanks
> >
> > _______________________________________________
> > 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/20130815/b8c1b293/attachment.html 
> 
> ------------------------------
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> End of Development Digest, Vol 23, Issue 74
> *******************************************