The layout in the original post looks a lot like how protobuf-net does RPC
over http. It uses {root}/service/method, but it would be trivial to tweak
it to use any similar pattern. I'd be happy to make tweaks to protobuf-net
to make it play the same game, and try a few cross-implementation scenarios.Marc 2009/12/10 Romain François <[email protected]> > 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 <[email protected] > > <mailto:[email protected]>> > > > > 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} > ProtobufMethod: {method full name} > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<protobuf%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/protobuf?hl=en. > > > -- Regards, Marc -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
