I'd like to see the pyramid_rpc to support MessagePack-RPC<http://wiki.msgpack.org/display/MSGPACK/RPC+specification>which is an enhanced RPC specification like JSON-RPC. It is simple but useful. I find the pyramid_rpc 0.4 does not support MessagePack-RPC yet. Is anybody there working on the MessagePack-RPC for pyramid?
If no one else, I'd like to write some code for it. I will be appreciate if can give me some advice for contributing some code to pyramid_rpc.
On Sun, Sep 30, 2012 at 3:09 PM, lvqier <lvq...@gmail.com> wrote:
> I'd like to see the pyramid_rpc to support MessagePack-RPC<http://wiki.msgpack.org/display/MSGPACK/RPC+specification>which is an enhanced RPC specification like JSON-RPC. It is simple but
> useful. I find the pyramid_rpc 0.4 does not support MessagePack-RPC yet. Is
> anybody there working on the MessagePack-RPC for pyramid?
> If no one else, I'd like to write some code for it. I will be appreciate
> if can give me some advice for contributing some code to pyramid_rpc.
> Thanks,
> lvqier
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/pylons-devel/-/3wODNdzYcLYJ.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
I couldn't understand what's the meaning of over-http RPC. As I understand, HTTP is a protocol that carries RPC data just like TCP and so on. Do you mean RPC protocols that run on HTTP should have something HTTP specific?
On Sunday, September 30, 2012 11:04:17 PM UTC+8, INADA Naoki wrote:
> MessagePack-RPC specification doesn't have over-http RPC. > It is suitable for in DC wire.
> On Sun, Sep 30, 2012 at 3:09 PM, lvqier <lvq...@gmail.com <javascript:>>wrote:
>> I'd like to see the pyramid_rpc to support MessagePack-RPC<http://wiki.msgpack.org/display/MSGPACK/RPC+specification>which is an enhanced RPC specification like JSON-RPC. It is simple but >> useful. I find the pyramid_rpc 0.4 does not support MessagePack-RPC yet. Is >> anybody there working on the MessagePack-RPC for pyramid?
>> If no one else, I'd like to write some code for it. I will be appreciate >> if can give me some advice for contributing some code to pyramid_rpc.
>> Thanks, >> lvqier
>> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-devel" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/pylons-devel/-/3wODNdzYcLYJ. >> To post to this group, send email to pylons...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> pylons-devel...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/pylons-devel?hl=en.
> I couldn't understand what's the meaning of over-http RPC. As I
> understand, HTTP is a protocol that carries RPC data just like TCP and
> so on. Do you mean RPC protocols that run on HTTP should have
> something HTTP specific?
XML-RPC is *defined* in terms of HTTP. The spec at the URL you posted
describes a custom (non-HTTP-based) wire protocol, which cannot possibly
be handled by a Pyramid app.
Tres.
- -- ===================================================================
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
I have compared the MessagePack-RPC to JSON-RPC 2.0 again. The biggest difference between MessagePack-RPC and JSON-RPC 2.0 is the Notification message. JSON-RPC 2.0 defines the Notification message as a sub-type of request message while MessagePack-RPC defines the Notification message as a stand-alone message type. This means the Notification message can be sent from client to server in the definition of JSON-RPC 2.0 while it can be sent from both side in MessagePack-RPC. At the same time, messages can not be sent from server to client proactively. Is this the main issue that you determines the MessagePack-RPC as a non-HTTP-based RPC protocol?
But in my opinion, we can change the MessagePack-RPC just a bit(Notification type message can only be sent from client side) to make it HTTP-based. MessagePack is a popular data format which allows binary data packed in the message while JSON-RPC and XML-RPC can not afford.
On Monday, October 8, 2012 8:15:28 PM UTC+8, Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> On 10/07/2012 10:38 PM, lvqier wrote: > > I couldn't understand what's the meaning of over-http RPC. As I > > understand, HTTP is a protocol that carries RPC data just like TCP and > > so on. Do you mean RPC protocols that run on HTTP should have > > something HTTP specific?
> XML-RPC is *defined* in terms of HTTP. The spec at the URL you posted > describes a custom (non-HTTP-based) wire protocol, which cannot possibly > be handled by a Pyramid app.
> Tres. > - -- > =================================================================== > Tres Seaver +1 540-429-0999 tse...@palladion.com<javascript:> > Palladion Software "Excellence by Design" http://palladion.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> I have compared the MessagePack-RPC to JSON-RPC 2.0 again. The biggest > difference between MessagePack-RPC and JSON-RPC 2.0 is the Notification > message. JSON-RPC 2.0 defines the Notification message as a sub-type of > request message while MessagePack-RPC defines the Notification message as a > stand-alone message type. This means the Notification message can be sent > from client to server in the definition of JSON-RPC 2.0 while it can be > sent from both side in MessagePack-RPC. At the same time, messages can not > be sent from server to client proactively. Is this the main issue that > you determines the MessagePack-RPC as a non-HTTP-based RPC protocol?
> But in my opinion, we can change the MessagePack-RPC just a > bit(Notification type message can only be sent from client side) to make it > HTTP-based. MessagePack is a popular data format which allows binary data > packed in the message while JSON-RPC and XML-RPC can not afford.
> On Monday, October 8, 2012 8:15:28 PM UTC+8, Tres Seaver wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1
>> On 10/07/2012 10:38 PM, lvqier wrote: >> > I couldn't understand what's the meaning of over-http RPC. As I >> > understand, HTTP is a protocol that carries RPC data just like TCP and >> > so on. Do you mean RPC protocols that run on HTTP should have >> > something HTTP specific?
>> XML-RPC is *defined* in terms of HTTP. The spec at the URL you posted >> describes a custom (non-HTTP-based) wire protocol, which cannot possibly >> be handled by a Pyramid app.
>> Tres. >> - -- >> =================================================================== >> Tres Seaver +1 540-429-0999 tse...@palladion.com >> Palladion Software "Excellence by Design" http://palladion.com >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>> At the same time, messages can not be sent from server to client >> proactively.
> I mean it the HTTP protocol.
>> On Monday, October 8, 2012 10:13:56 PM UTC+8, lvqier wrote:
> Thank you for your replies.
>> I have compared the MessagePack-RPC to JSON-RPC 2.0 again. The biggest >> difference between MessagePack-RPC and JSON-RPC 2.0 is the Notification >> message. JSON-RPC 2.0 defines the Notification message as a sub-type of >> request message while MessagePack-RPC defines the Notification message as a >> stand-alone message type. This means the Notification message can be sent >> from client to server in the definition of JSON-RPC 2.0 while it can be >> sent from both side in MessagePack-RPC. At the same time, messages can not >> be sent from server to client proactively. Is this the main issue that >> you determines the MessagePack-RPC as a non-HTTP-based RPC protocol?
>> But in my opinion, we can change the MessagePack-RPC just a >> bit(Notification type message can only be sent from client side) to make it >> HTTP-based. MessagePack is a popular data format which allows binary data >> packed in the message while JSON-RPC and XML-RPC can not afford.
>> On Monday, October 8, 2012 8:15:28 PM UTC+8, Tres Seaver wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1
>>> On 10/07/2012 10:38 PM, lvqier wrote: >>> > I couldn't understand what's the meaning of over-http RPC. As I >>> > understand, HTTP is a protocol that carries RPC data just like TCP and >>> > so on. Do you mean RPC protocols that run on HTTP should have >>> > something HTTP specific?
>>> XML-RPC is *defined* in terms of HTTP. The spec at the URL you posted >>> describes a custom (non-HTTP-based) wire protocol, which cannot possibly >>> be handled by a Pyramid app.
>>> Tres. >>> - -- >>> =================================================================== >>> Tres Seaver +1 540-429-0999 tse...@palladion.com >>> Palladion Software "Excellence by Design" http://palladion.com >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (GNU/Linux) >>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> But msgpack-rpc's specification doesn't specify how it over HTTP.
> (WebSocket, SPDY, HTTP Pipelining or chunked encoding.)
> MessagePack-RPC is for stream like pipe, unix domain socket and TCP.
> There are no official specification for REQ/REP protocol like HTTP.
> But I think implementing simple REQ/REP RPC is enough for most cases.
> 2012年10月8日月曜日 23時18分03秒 UTC+9 lvqier:
>> Sorry for my unfinished sentience.
>>> At the same time, messages can not be sent from server to client >>> proactively.
>> I mean it the HTTP protocol.
>>> On Monday, October 8, 2012 10:13:56 PM UTC+8, lvqier wrote:
>> Thank you for your replies.
>>> I have compared the MessagePack-RPC to JSON-RPC 2.0 again. The biggest >>> difference between MessagePack-RPC and JSON-RPC 2.0 is the Notification >>> message. JSON-RPC 2.0 defines the Notification message as a sub-type of >>> request message while MessagePack-RPC defines the Notification message as a >>> stand-alone message type. This means the Notification message can be sent >>> from client to server in the definition of JSON-RPC 2.0 while it can be >>> sent from both side in MessagePack-RPC. At the same time, messages can not >>> be sent from server to client proactively. Is this the main issue that >>> you determines the MessagePack-RPC as a non-HTTP-based RPC protocol?
>>> But in my opinion, we can change the MessagePack-RPC just a >>> bit(Notification type message can only be sent from client side) to make it >>> HTTP-based. MessagePack is a popular data format which allows binary data >>> packed in the message while JSON-RPC and XML-RPC can not afford.
>>> On Monday, October 8, 2012 8:15:28 PM UTC+8, Tres Seaver wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1
>>>> On 10/07/2012 10:38 PM, lvqier wrote: >>>> > I couldn't understand what's the meaning of over-http RPC. As I >>>> > understand, HTTP is a protocol that carries RPC data just like TCP >>>> and >>>> > so on. Do you mean RPC protocols that run on HTTP should have >>>> > something HTTP specific?
>>>> XML-RPC is *defined* in terms of HTTP. The spec at the URL you posted >>>> describes a custom (non-HTTP-based) wire protocol, which cannot >>>> possibly >>>> be handled by a Pyramid app.
>>>> Tres. >>>> - -- >>>> =================================================================== >>>> Tres Seaver +1 540-429-0999 tse...@palladion.com >>>> Palladion Software "Excellence by Design" http://palladion.com >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.11 (GNU/Linux) >>>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
