[Development] [Feature Request] Websockets
Christian Gagneraud
chgans at gna.org
Tue Aug 20 00:17:39 CEST 2013
On 18/08/13 05:08, Matt Broadstone wrote:
> On Sat, Aug 17, 2013 at 4:17 AM, Kurt Pattyn <pattyn.kurt at gmail.com
> <mailto:pattyn.kurt at gmail.com>> wrote:
>
> Well,
>
> it is a fact that Qt has little to no native support for 'cloud'
> based client and server 'protocols', like REST, WebSockets, SOAP,
> aso. So, it would indeed be a nice addition to have support for the
> most popular 'protocols'.
> Should we have something like a QNetworkAccessManager with pluggable
> protocols, or do we create a protocols module with just independent
> classes?
> I prefer the latter but the classes should at least have some
> consistent API.
>
>
>
> Frankly, I'm of a mind that we just take the existing projects and put
> them in the module at least for starters. Sure, it would probably be
> pretty cool to have some sort of unified system, but we're not going to
> make that anytime soon. Furthermore, at least in qjsonrpc/qxmpp/kdsoap's
> case, these are pretty mature projects, and I would hate to see a lot of
> wheel re-inventing just for the sake the "grand unified vision."
>
> I'm also a bit of a mind that the "grand unified protocol" idea might be
> a bit of a red herring: what parts of these systems do we in fact need
> to share? QIODevice, Q[Udp/Tcp][Server/Socket], maybe some data streams,
> json/xml parsers, these are all provided by Qt. My goal with suggesting
> that we put these into a module together is twofold: first, centralize
> the development of these solutions and hopefully attract developers to
> work on these instead of rolling their own (case in point, Christian's
> first email cites that he's interested in a "JSON based protocol that
> could go through a QIODevice," well hey isn't that qjsonrpc?). Secondly,
> to provide the opportunity for a more rigorous peer review of the code
> from this great development community.
The protocol layer design pattern sounds nice, and I do agree with Kurt,
having that pluggable to the QNetworkAccessManager would be really cool.
Nonetheless, I do agree with Matt too, before speaking about unifying
things, it would be a good start to group these kind of projects
together. Plus, the fact that they will inherit all the QA stuff from
the Qt project.
To answer Matt about my usecase, yes qjsonrpc sounds like a very good
candidate. And my example make a point. If these projects were all in
one place, I would have certainly pickup qjsonrpc straight away, right
now, I have to google a lot to find candidates to base my work on.
And usually (but not always), these projects are not provided by my
distro or are a bit too old, so I have to build them one by one, install
them in a centralised place, and then add them to my project file, I
would prefer a quick and straightforward CONFIG += QNetworkExtra or
something similar.
So, definitely +1 for an addon umbrella for all these guys.
Regards,
Chris
>
> Matt
>
> On 16 Aug 2013, at 19:10, Matt Broadstone <mbroadst at gmail.com
> <mailto:mbroadst at gmail.com>> wrote:
>
>> On Thu, Aug 15, 2013 at 6:59 PM, Christian Gagneraud
>> <chgans at gna.org <mailto:chgans at gna.org>> wrote:
>>
>> On 16/08/13 03:41, Matt Broadstone wrote:
>> > On Wed, Aug 14, 2013 at 11:54 AM, Kurt Pattyn
>> <pattyn.kurt at gmail.com <mailto:pattyn.kurt at gmail.com>
>> > <mailto:pattyn.kurt at gmail.com
>> <mailto:pattyn.kurt at gmail.com>>> wrote:
>> >
>> > Hi,
>> >
>> > I opensourced a Qt based module that implements the web
>> socket
>> > protocol. The repository can be found here:
>> > https://github.com/KurtPattyn/QWebSockets.
>> > I have 2 questions:
>> > 1. Is there any interest in adding this to Qt?
>> > 2. If so, should this be added to QtNetwork or is a
>> add-on preferred?
>> >
>> >
>> > Perhaps it would be best to have something like a
>> qtprotocols addon. I'm
>> > also interested in maybe getting qjsonrpc pushed upstream to the
>> > qt-project, there has been some interest in the community
>> and I think it
>> > could benefit from more eyes on it. I'm also in the process
>> of writing a
>> > somewhat more streamlined STOMP client for qt that could
>> live there as
>> > well.
>>
>> Are you talking about https://bitbucket.org/devonit/qjsonrpc ?
>> The nice thing if the 2 projects belongs to the same addon is
>> that they
>> can use each other, right? In that case, it would be possible
>> to add a
>> QJsonRpcWebsocketServer without adding external dependencies.
>>
>>
>> Yes I am.
>>
>> Sure, they could use each other but I'm not sure how much you gain
>> there. I haven't really looked into the websocket standard, but
>> I'm not sure it shares many similarities with jsonrpc, please
>> correct me if I'm wrong. I was simply suggesting that there seem
>> to be a number of protocol implementations for Qt and they might
>> be best served grouped in a new addon module (qjsonrpc,
>> qwebsockets, qstompclient, qxmpp, etc).
>>
>> Matt
>>
>> My 2 cents,
>> Chris
>>
>>
>> >
>> > Thoughts?
>> > Matt
>> >
>> > Best regards,
>> >
>> > Kurt Pattyn
>> > _______________________________________________
>> > Development mailing list
>> > Development at qt-project.org
>> <mailto:Development at qt-project.org>
>> <mailto:Development at qt-project.org
>> <mailto:Development at qt-project.org>>
>> > http://lists.qt-project.org/mailman/listinfo/development
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Development mailing list
>> > Development at qt-project.org <mailto:Development at qt-project.org>
>> > http://lists.qt-project.org/mailman/listinfo/development
>> >
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org <mailto:Development at qt-project.org>
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>
More information about the Development
mailing list