----- Alkuperäinen viesti -----
Lähettäjä: "[email protected]" 
<[email protected]>
Lähetetty: ‎17.‎8.‎2013 13:00
Vastaanottaja: "[email protected]" <[email protected]>
Aihe: Development Digest, Vol 23, Issue 86

Send Development mailing list submissions to
        [email protected]

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
        [email protected]

You can reach the person managing the list at
        [email protected]

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 <[email protected]>
Subject: Re: [Development] [Feature Request] Websockets
To: Matt Broadstone <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID: <[email protected]>
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 <[email protected]> wrote:

> On Thu, Aug 15, 2013 at 6:59 PM, Christian Gagneraud <[email protected]> wrote:
>> On 16/08/13 03:41, Matt Broadstone wrote:
>> > On Wed, Aug 14, 2013 at 11:54 AM, Kurt Pattyn <[email protected]
>> > <mailto:[email protected]>> 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
>> >     [email protected] <mailto:[email protected]>
>> >     http://lists.qt-project.org/mailman/listinfo/development
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Development mailing list
>> > [email protected]
>> > http://lists.qt-project.org/mailman/listinfo/development
>> >
>> 
>> _______________________________________________
>> Development mailing list
>> [email protected]
>> 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 <[email protected]>
Subject: Re: [Development] [Feature Request] Websockets
To: [email protected]
Message-ID: <[email protected]>
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 <[email protected] 
> <mailto:[email protected]>> wrote:
>
>> On Thu, Aug 15, 2013 at 6:59 PM, Christian Gagneraud <[email protected] 
>> <mailto:[email protected]>> wrote:
>>
>>     On 16/08/13 03:41, Matt Broadstone wrote:
>>     > On Wed, Aug 14, 2013 at 11:54 AM, Kurt Pattyn
>>     <[email protected] <mailto:[email protected]>
>>     > <mailto:[email protected] <mailto:[email protected]>>>
>>     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
>>     > [email protected] <mailto:[email protected]>
>>     <mailto:[email protected]
>>     <mailto:[email protected]>>
>>     > http://lists.qt-project.org/mailman/listinfo/development
>>     >
>>     >
>>     >
>>     >
>>     > _______________________________________________
>>     > Development mailing list
>>     > [email protected] <mailto:[email protected]>
>>     > http://lists.qt-project.org/mailman/listinfo/development
>>     >
>>
>>     _______________________________________________
>>     Development mailing list
>>     [email protected] <mailto:[email protected]>
>>     http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>
>
> _______________________________________________
> Development mailing list
> [email protected]
> 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
[email protected]
http://lists.qt-project.org/mailman/listinfo/development


End of Development Digest, Vol 23, Issue 86
*******************************************
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to