Out of the several specifications, a problem I find is they all use
serialized messages as a byte string as part of the message. That's
inefficient and in the case of C++ involves triple-copying - from
socket buffer to kernel buffer to user buffer to parsed message. At
the very least that last c
On Tue, Oct 28, 2008 at 9:07 PM, Pavel Shramov <[EMAIL PROTECTED]> wrote:
> By the way one of the simpliest ways for RPC is to use HTTP transport.
> It's have some limitations (e.g large overhead for small messages) but
> also some benefits (e.g many libraries for performing HTTP calls and
> simpl
On Tue, Oct 28, 2008 at 11:46:19AM -0700, Kenton Varda wrote:
> Ever notice how practically no one uses HTTP auth? :)
By the way one of the simpliest ways for RPC is to use HTTP transport.
It's have some limitations (e.g large overhead for small messages) but
also some benefits (e.g many librarie
Ever notice how practically no one uses HTTP auth? :)
On Tue, Oct 28, 2008 at 1:16 AM, Paul P. Komkoff Jr <[EMAIL PROTECTED]>wrote:
>
> On Oct 28, 2:02 am, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> > I don't really have a stake in the design of a protobuf-based RPC format.
> > However, I'd li
Authentication doesn't really belong here. You should either use an
authenticated transport (like HTTPS), or in the layer above (this is
what I'm currently doing).
On Oct 27, 8:54 pm, "Paul P. Komkoff Jr" <[EMAIL PROTECTED]> wrote:
> On 26 окт, 02:53, Alan Kligman <[EMAIL PROTECTED]> wrote:
>
> >
Paul - I haven't looked at protobuf-rpc, but protorpc uses a .proto
message for the payload. One up-shot of that is that it should be (in
theory at least) fine to add extension properties to the message -
i.e. you could add a security object as an extended property. A given
server could check for
On Oct 28, 2:02 am, "Kenton Varda" <[EMAIL PROTECTED]> wrote:
> I don't really have a stake in the design of a protobuf-based RPC format.
> However, I'd like to point out that the design philosophy we tend to prefer
> at Google is to keep each layer of the system as simple as possible, and
> impl
I'm currently working on the guts of a protorpc layer for protobuf-
net; so yes, any conversations here are very valued. Especially re
test rigs ;-p
I don't have any huge bias for/against either of the cited specs
(protorcp/protobuf-rpc). I just want something that works ;-p
Marc
--~--~-
I don't really have a stake in the design of a protobuf-based RPC format.
However, I'd like to point out that the design philosophy we tend to prefer
at Google is to keep each layer of the system as simple as possible, and
implement orthogonal features using separate layers. Authentication is a
g
On 26 окт, 02:53, Alan Kligman <[EMAIL PROTECTED]> wrote:
> I haven't had much to add recently. Protobuf-rpc is based heavily on
> json-rpc, so there's really nothing new behind it. It works well for
> my own use and is generic enough to probably work well for most other
> people.
>
> Is there a g
I haven't had much to add recently. Protobuf-rpc is based heavily on
json-rpc, so there's really nothing new behind it. It works well for
my own use and is generic enough to probably work well for most other
people.
Is there a great deal of interest in devising a standard rpc protocol
definition?
This whole conversation (proto / rpc) seems to have been very quiet
for a while. I'd be very keen to implement rpc for protobuf-net, so /
any/ kind of consensus would be good. I suppose I'd default to the
more Java compatible, but...
Marc
--~--~-~--~~~---~--~~
You
Google's RPC system is huge and bloated, and designed explicitly for our
hardware and data center configurations. So, I don't think publishing our
protocol would be very helpful, and it would take a lot of work just to
document it properly. I'm not even sure if our protocol makes sense for use
ov
To make different RPC implementations based on Protocol Buffers
compatible with each other, they must use the same method of data
serialization. However, it's not the case for RPC service fields like
method name or message id:
Java project Protorcp uses one specificaton (http://
protorpc.likbilen
14 matches
Mail list logo
