On 12/10/2009 11:13 AM, Kenton Varda wrote:
> 2009/12/10 Romain François <[email protected]
> <mailto:[email protected]>>
>
> 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 .
>
>
> No, that's not what I'm suggesting. The client doesn't start from "I
> want to use FooService.". The client starts from "I want to talk to
> http://example.com/foo-service, which I already know is of type
> FooService.". It doesn't make sense for the client to ask the server
> where to find a FooService, because the server might expose *multiple*
> FooServices. The client has to know which one it wants to talk to. The
> URL identifies that.
Ah. I think I understand now.
For me the method full name uniquely identifies the method and the
server is generic, serving a service/method if it knows about it.
Anyway, for those interested my code is here:
$ svn checkout svn://svn.r-forge.r-project.org/svnroot/rprotobuf/java
$ ant
$ ./start.sh
Implementing a method involves subclassing the ProtobufMethodInvoker
class which is generic (on both input and output type). So for example
with this service:
service EchoService {
rpc Echo (Person) returns (Person);
}
I define the EchoInvoker class like this :
package org.rproject.rprotobuf ;
import com.example.tutorial.AddressBookProtos.Person ;
import com.google.protobuf.Message ;
@MethodImplementation("tutorial.EchoService.Echo")
public class EchoInvoker extends ProtobufMethodInvoker<Person,Person>{
public Person invoke(Person person){
return person ;
}
public Person getInputDefaultInstance(){
return
com.example.tutorial.AddressBookProtos.Person.getDefaultInstance() ;
}
}
The method invoker must be registered using the
ProtobufMethodPool.register method. For example :
register("tutorial.EchoService.Echo", new EchoInvoker() ) ;
I'm planning on adding some scanning based on the @MethodImplementation
annotation.
Romain
> 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]>
> <mailto:[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]>>
> > <mailto:[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.
