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.
