> 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:
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;
2) PB is a very efficient binary format so tying it up to a less than
optimal text-based HTTP seems to be counterproductive;
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.);
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.
That's my 2c.
Regards,
On Dec 10, 10:30 am, Marc Gravell <marc.grav...@gmail.com> wrote:
> For info only, protobuf-net currently uses:
>
> internal const string HTTP_RPC_VERSION_HEADER = "pb-net-rpc";
> internal const string HTTP_RPC_MIME_TYPE = "application/x-protobuf"
> ;
> (version for my own internal purposes, in case I need to change the body
> layout)
>
> 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...? I'd rather not get
> bogged down in trying to predict every nuance of sockets, when people can
> always (for now) "do their own thing" using protocol buffers just for
> serialization.
>
> Marc
>
> 2009/12/10 Romain François <francoisrom...@free.fr>
>
>
>
> > On 12/10/2009 04:30 PM, Pavel Shramov wrote:
>
> >> On Wed, Dec 09, 2009 at 12:10:33PM +0100, Romain François wrote:
>
> >>> Hello,
>
> >>> Following Kenton's advice, I'm starting to look at implementing protobuf
> >>> rpc over http. I have started to work on a basic java server (based on
> >>> the com.sun.net.httpserver class). I will post this at some point when I
> >>> am happier with it (currently it can only serve one dummy service that
> >>> returns the input message as is)
>
> >>> A request looks like this :
>
> >>> -----------------------------------------------------
> >>> POST /{service full name}/{method name} HTTP/1.0
> >>> Connection: close
>
> >>> Content-Length: {length of the serialized message}
>
> >>> {raw bytes of the serialized message}
> >>> -----------------------------------------------------
>
> >> I'm using method name encoded in query part of URL like
> >> /base/url?Service.Method
>
> > That seems odd. Why not /base/url?service=Service&method=Method instead ?
>
> > Also it's seem useful to provide Content-Type to distinguish between
> >> different
> >> encodings of message (for example JSON).
>
> > Yep. Will add this.
>
> > And a successful response looks like this:
>
> >>> -----------------------------------------------------
> >>> HTTP/1.1 200 OK
> >>> Content-length: {length of the serialized response}
>
> >>> {raw bytes of the serialized response}
> >>> -----------------------------------------------------
>
> >> Also it may be useful to state that errors are transmitted as body of
> >> 500 Internal Server Error response.
>
> >> For my implementation You may see [1] and [2] for python and C++ HTTP
> >> client.
>
> > I will. So this makes 3 very similar http based protocols, but slightly
> > different. We should come to an agreement. :-)
>
> > Pavel
>
> >> [1]http://grid.pp.ru/wiki/pbufrpc
> >> [2]http://grid.pp.ru/cgit/pbufrpc
>
> > --
> > Romain Francois
> > Professional R Enthusiast
> > +33(0) 6 28 91 30 30
> >http://romainfrancois.blog.free.fr
> > |-http://tr.im/Gq7i: ohloh
> > |-http://tr.im/FtUu: new package : highlight
> > `-http://tr.im/EAD5: LondonR slides
>
> --
> Regards,
>
> Marc
--
Mikhail Opletayev
http://dataflow-software.com
--
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.
