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.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.


Reply via email to