On Thu, Dec 10, 2009 at 2:37 PM, Mikhail Opletayev <opleta...@gmail.com>wrote:
> 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? > Currently it references them by an ID number that is tied to the particular connection. So, each time a new service object is returned on the connection, a new ID number is assigned to it. > Also, is it going to be an extension to pbcap or something completely > new? Not an extension -- this *is* pbcap. It supports this already. (Note that I'm planning to change the name to "Captain Proto", aka capnproto, to avoid the confusion with pcap.) > 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. > What do you mean? The global "Stream" message exists only to define the protocol. It is not actually used at runtime -- individual messages are read from the stream one at a time. > > 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> > <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@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<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.
