On Thu, Dec 10, 2009 at 8:13 AM, Mikhail Opletayev <opleta...@gmail.com>wrote:
> 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. > This is exactly my point. If you use the service type name to identify the service, then you can only export one service of each type. Instead, some other name -- having nothing to do with the type name -- should be used to identify the service. Actually, the implementation I'm working on doesn't even identify services by names. Instead, when you first connect on a port, you connect to the "default service" for that port. However, the default service can send back pointers to other services in RPC responses. So, the default service may have a method which looks up other services by name, but this is up to the application. > > 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<protobuf%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/protobuf?hl=en. > > > -- 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.
