Interesting. Essentially a discovery service for protobuf RPC. I am not quite sure what you mean by "pointers to other services". Is it going to reference them by name or a more complex structure containing full endpoint information?
Also, is it going to be an extension to pbcap or something completely new? The reason I am asking is because some patterns in pbcap (such as wrapping up everything into a global Stream message) are rather questionable and not without consequences. Regards, On Dec 10, 4:22 pm, Kenton Varda <ken...@google.com> wrote: > 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. -- 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.
