Cool. Do you have your layout documented somewhere in your project.
Embed service full name and method name in the http request as we do
allows the request to be self-contained. What kenton suggests needs the
client to know of the mapping between the service full name (in pb
speech) and the http service name, which might then need an independant
exchange before hand between the client and the server .
client: how do you call this service
server: foo
client: sending the http request using foo
Either way is fine. It would be good to all agree on what rpc over http
means.
On 12/10/2009 10:15 AM, Marc Gravell wrote:
>
> 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]
> <mailto:[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]>
> > <mailto:[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].
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
