On Fri, Mar 12, 2010 at 04:17:37PM -0500, Andrew Kimpton wrote:
> I've started a small project at
> https://code.google.com/p/protobuf-jerpc/which contains an
> implementation of a protoc plugin that outputs essentially
> the same classes etc that the current generic services mechanism outputs
> (but in a different namespace).
Great. Saving "official" rpc interface is important even with namespace changed.
> Also in the project is a very simple C++ implementation of an RPC server
> which can receive requests via a socket connection using protocol buffers.
Message format used for socket communication seem to be synchronous by design.
Why not to add 'id' field for binding responses with requests to allow async
services?
Why I'm interested?
Since all services (maybe except http ones) are incompatible most of them share
common
design and only have different wire format (simple ones). Services with common
set of features may be simply modified to be compatible to each other by using
another protocol definition. For example, my python rpc service may be adopted
to
work with yours cpp implementation and vice versa. Why to bother? I hope that
if some
RPC implementations became compatible with each other (maybe via compatibility
layers)
it will be easier to find impl that fit yours needs.
Pavel
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
