Disclaimer: I'd be happy if once one of raw async RPC would be
'standart' but now maybe HTTP one will be. They just suppliment each other.
On Thu, Dec 10, 2009 at 09:41:15AM -0800, Mikhail Opletayev wrote:
> > Re the sockets point also raised; there's a lot of difference between raw
> > sockets and http; it would be good to get some kind of "official" http
> > transport working - people can always add raw later...?
>
> This is exactly the point I was trying to raise: if you bind Protocol
> Buffer RPC to a transport protocol then you can't easily use different
> transports as they might lack certain features. I mentioned TCP
> sockets just as an example.
>
> Here is my line of thought behind using a more generic (less HTTP-
> dependent) approach:
Nobody argues that non-HTTP RPC must exists. But raw transport needs some
kind of envelope (or header as in dataflow's pbuf-rpc) and thus a bit more
complicated (as protocol).
> 1) Not all protobufs target applications have an HTTP stack available.
> I know some applications that could use protobuf RPC but don't have
> HTTP available;
Then it's not place for RPC over HTTP :) But there is place for it.
> 2) PB is a very efficient binary format so tying it up to a less than
> optimal text-based HTTP seems to be counterproductive;
Sometimes You need slow non-efficient protocol for stateless calls or when
they are rare and must survive server restart.
> 3) It is a common practice to make RPC protocols self contained, and
> having a message carry all the information needed for its delivery
> (JSON RPC, SOAP, COBRA, Java RMI, etc.);
BTW have you seen/used non-HTTP SOAP transports? :) Not on slides but in
real life?
> 4) To achieve #3, no service or method name can be coded externally,
> no custom transport protocol features can be used either (HTTP
> headers);
>
> 5) Using protobuf to define header messages feels right as its easy to
> parse with the existing tools and it allows for a greater
> extensibility and "soft versioning" with optional fields;
>
> 6) Self contained RPC messages don't just enable using different
> transports. You can do a whole lot more: safely and easily persist
> messages, batch them which can greatly improve throughput;
>
> 7) It simplifies the RPC protocol specification. Header messages can
> be declared as a .proto file, people can compile it for their own
> platforms. It seems to be in line with the general protobuf
> philosophy.
Simpliest RPC implementation is one over HTTP since only part that needs
external specification is 'calling conventions' for mathod to URL
translation.
Pavel
P.S. Sorry for flaming :)
--
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.
