Both methods that you mention will work and are fairly common. The first is
generally preferred because you're less likely to have type errors, and
debugging tools can show you more of RPCBuffer (e.g. the rpc library could
print the DebugString of the RPCBuffer in debugging mode, showing exactly
what's in the message).
In terms of performance, the second approach will make one extra string copy
of messageBuffer -- it shouldn't be a significant issue unless the code is
extremely cpu and memory sensitive.
Within Google we handle the unique id issue by using changelist numbers --
our source control system generates unique numbers for every change, so it's
pretty easy to just use those numbers as the field ids.
Daniel
On Tue, Aug 9, 2011 at 7:52 AM, Dave <dave.johns...@me.com> wrote:
> Hi,
>
> We have some legacy code, that provides an RPC library for several
> services. All RPC messages have a "handler" name, which is used to
> determine which callback, a message should be sent to when it is
> received (when a service starts up it registers 1 or more handlers).
> I have been working towards replacing the marshalling/unmarshalling
> code with google protocol buffers, and currently have messages like
> this:
>
> message RPCBuffer {
> required string handler = 1;
> extensions 100 to max;
> }
>
> message example {
>
> extend RPCBuffer {
> optional string name = 110;
> optional int32 num = 111;
> }
> }
>
> Now the legacy code behaves the same way as before, when it receives a
> message it uses a ParseFrom method to construct the RPCBuffer protocol
> buffer. It then gets the 'handler', and uses it to send the entire
> buffer to the appropriate callback. The callback then uses the
> extensions API to access data from inside the buffer.
>
> This works, but I can see it getting messy, as over time the different
> services that extend RPCBuffer, have to make sure that they use unique
> identifiers.
>
>
> An alternative approach maybe this:
>
> message RPCBuffer {
> required string handler = 1;
> required bytes messageBuffer = 2;
> }
>
> message example {
> required string name = 1;
> required int32 num = 2;
> }
>
> The code will still, use the handler name to determine which callback
> to call, but instead of passing the entire protocol buffer, it would
> pass the 'messageBuffer'. The callback, would then construct the
> 'example' protocol buffer, calling ParseFrom and passing in the
> messageBuffer. The callback, can then access the data members uses
> the usual google protocol buffer API.
>
> The only problem I have with the second approach, is that there are
> effectively two unmarshalls (ParseFrom(....) is called twice, once on
> the RPCBuffer, and then once on the example buffer). Will this
> provide significant overhead in terms of memory and CPU ?
>
> Any comments/suggestions ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to protobuf@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.
>
>
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to protobuf@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.
