It's great news that you working on a standard way to communicate
between Protocol Buffers implementations!

> You don't need to send the service name at all.  The server should already
> know what kind of service it is exporting.

I think its handy to export several services from the same end point,
especially if you are running RPC over something else than HTTP. If
you were to run Protocol Buffers RPC over plain sockets you'd probably
want to publish a bunch of services on the same port.

In Dataflow implementation we use one field (method) but we require
the method name to be in "serviceName.methodName" format.

For the same reason we decided against using HTTP headers to transfer
the RPC metadata as it binds you to the transport protocol. That's why
send content length and header length as the first 2 values in the
coded stream, then the header message, then the actual data message:

http://www.dataflow-software.com/docs/pbuf-rpc.html

On Dec 10, 3:15 am, Kenton Varda <ken...@google.com> wrote:
> 2009/12/10 Romain François <francoisrom...@free.fr>
>
>
>
> > On 12/09/2009 09:12 PM, Kenton Varda wrote:
>
> >> Coincidentally, last weekend I started working on an open source
> >> protobuf-based RPC system.  Currently I am defining a socket-level
> >> protocol, but I also intend to support an HTTP-level protocol with
> >> optional JSON encoding to allow calls from Javascript.  I stuck some
> >> totally undocumented code here:
>
> > Thanks. My intention of having it over http is that it can communicate with
> > other languages. I'd be good if we can synchronize our protocols.
>
> > I need to make some changes based on what you said on another thread, and
> > then I'll make my java basic server code available.
>
> >  http://pbcap.googlecode.com
>
> >> But some coworkers pointed out that the name is confusingly similar to
> >> "pcap", so I'm planning to change it.
>
> >> Currently this is not an official Google project; I'm working on it in
> >> my spare time.
>
> >> 2009/12/9 Romain François <francoisrom...@free.fr
> >> <mailto:francoisrom...@free.fr>>
>
> >>    A request looks like this :
>
> >>    -----------------------------------------------------
> >>    POST /{service full name}/{method name} HTTP/1.0
>
> >> I would recommend against putting the service type name in the URL.
> >>  This makes it impossible to export two services of the same type.
> >>  Instead, you should allow the application to register services under
> >> any name it chooses.
>
> > Fair enough. Maybe adding some protobuf specific headers :
>
> > ProtobufService: {service full name}
>
> You don't need to send the service name at all.  The server should already
> know what kind of service it is exporting.
>
> > ProtobufMethod: {method full name}
>
> You do need the method name, though.  Inventing new HTTP headers isn't
> usually a good idea as they may confuse proxies and such.
>
>
>
> > or encode it as parameters of the url as you said.
>
> >  I'd also suggest making the method name be part of the query, like:
>
> >>   POST /someservice?method={method name}
>
> >> This may be a matter of taste, but I feel like a service object should
> >> be a single HTTP "resource", rather than have each method be a separate
> >> resource.
>
> >>    Connection: close
>
> >> Why not allow pipelining?
>
> > this was simpler to do a one shot service call, but indeed why not.
>
> >     Content-Length: {length of the serialized message}
>
> >>    {raw bytes of the serialized message}
> >>    -----------------------------------------------------
>
> >>    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}
> >>    -----------------------------------------------------
>
> >>    Since this is very early in this, I wondered if others would have views
> >>    on this.
>
> >>    http is quite verbose for sending protobuf message around, but it is
> >>    likely to be implemented for a lot of languages.
>
> >>    Regards,
>
> >>    Romain
>
> > --
> > 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

--

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.


Reply via email to