MessagePack-RPC support by pyramid_rpc

[lvqier]

I'd like to see the pyramid_rpc to support MessagePack-RPC 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

[INADA Naoki]

MessagePack-RPC specification doesn't have over-http RPC.

It is suitable for in DC wire.

--
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.
To unsubscribe from this group, send email to pylons-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.

--
INADA Naoki  <songof...@gmail.com>

[lvqier]

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?

[Tres Seaver]

-----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/

iEYEARECAAYFAlByw9MACgkQ+gerLs4ltQ7dFACgykkaTFSOBatzZhThyjrtRN+X
AjEAn1XM3gMKy3JqkzqW4U+4J9GBa3YI
=f49x
-----END PGP SIGNATURE-----

[lvqier]

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.

[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.

[INADA Naoki]

MessagePack-RPC allows asynchronous request.

Client   Server
 --- REQ1 -->
 --- REQ2 -->
 <-- RES2 ---
 <-- RES1 ---

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:

[lvqier]

Thanks a lot for your explanation.

Anyway, how does JSON-RPC 2.0 over-HTTP work? I think we can implement MessagePack-RPC like JSON-RPC 2.0.