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}
>
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 [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.
