[Development] Development Digest, Vol 23, Issue 86
Antonio
antonio.cano.gomez at ovi.com
Mon Aug 19 07:28:23 CEST 2013
----- Alkuperäinen viesti -----
Lähettäjä: "development-request at qt-project.org" <development-request at qt-project.org>
Lähetetty: 17.8.2013 13:00
Vastaanottaja: "development at qt-project.org" <development at qt-project.org>
Aihe: Development Digest, Vol 23, Issue 86
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 (Kurt Pattyn)
2. Re: [Feature Request] Websockets (Denis Shienkov)
----------------------------------------------------------------------
Message: 1
Date: Sat, 17 Aug 2013 10:17:21 +0200
From: Kurt Pattyn <pattyn.kurt at gmail.com>
Subject: Re: [Development] [Feature Request] Websockets
To: Matt Broadstone <mbroadst at gmail.com>
Cc: "development at qt-project.org" <development at qt-project.org>
Message-ID: <78D070FA-48B8-4E2A-9358-36FB739EDB60 at gmail.com>
Content-Type: text/plain; charset="us-ascii"
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.
On 16 Aug 2013, at 19:10, Matt Broadstone <mbroadst at gmail.com> wrote:
> On Thu, Aug 15, 2013 at 6:59 PM, Christian Gagneraud <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>> 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>
>> > http://lists.qt-project.org/mailman/listinfo/development
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Development mailing list
>> > Development at qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/development
>> >
>>
>> _______________________________________________
>> 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/20130817/7da95b94/attachment-0001.html
------------------------------
Message: 2
Date: Sat, 17 Aug 2013 12:46:00 +0400
From: Denis Shienkov <scapig2 at yandex.ru>
Subject: Re: [Development] [Feature Request] Websockets
To: development at qt-project.org
Message-ID: <520F3848.1040208 at yandex.ru>
Content-Type: text/plain; charset="iso-8859-1"
Hi all.
> I prefer the latter but the classes should at least have some
consistent API.
This concept it is possible to expand and enter the general base class
or pattern of Protocol (or something like Protocols framework, by
analogy with QStateMachine framework). This class (or set of classes)
shall be based on the ISO/OSI model and accept as the input parameter of
QIODevice.
Then each user will be able derive from this pattern and to create any
communications protocols, using some basic API / concept.
For example, it would be possible to create plug-ins and for industrial
Modbus, DNP3, IEC101-104 protocols, etc., and not just WebSockets, SOAP
and etc.
E.g. we can be take as base "Protocol Layer Design Pattern" :
http://www.eventhelix.com/realtimemantra/patterncatalog/protocol_layer.htm#.Ug835n_CcZ4
or something like....
Best regards,
Denis
17.08.2013 12:17, Kurt Pattyn ?????:
> 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.
>
>
> 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
>>
>>
>
>
> _______________________________________________
> 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/20130817/559693be/attachment-0001.html
------------------------------
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
End of Development Digest, Vol 23, Issue 86
*******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130819/3b5908b6/attachment.html>
More information about the Development
mailing list