Hi Hassan,
The protocol buffers library actually contains a class called DynamicMessage
in C++ and Java which works more like what you describe. There's two
reasons that we prefer the generated classes:
* They are an order of magnitude faster than DynamicMessage. Generated code
can be made *extremely* fast compared with dynamic code. We find that we
need this performance for things we do at Google.
* The dynamic approach is not type-safe. For example, if you want to get
the value of an int32 field, you have to make sure to call the GetInt32()
accessor, not GetInt64() or GetString(), etc. Errors are only detected at
runtime, which is bad. With generated classes, the accessor methods are
generated for us, which allows the compiler to do type checking. (Also,
they are less verbose, but that's more of a bonus.)
On Sat, Feb 14, 2009 at 10:02 AM, h.a.s...@gmail.com wrote:
Hi Guys,
I have started lightly browsing over the source code of the
implementation of protocol buffers, I have built a high performance
telemetry system as part of my research, this includes a custom
messaging system with a over the wire format. I have been considering
rewriting the system to use protocol buffers when I have time.
To my understanding protocol buffers is a message delivery system
first and a rpc mechanism second. Now I am wondering why protocol
buffers didn't go with dynamic message typing (by this I mean not
having to generate skeletons).
Something along the lines of :
#DEFINE LOGIN_EVENT_TYPE 0
char * userNameEntry=foo;
RpcChannel logDaemonConnection=new RpcChannel(/tmp/Logdaemon);
Message logMsg= new Message(UserLoginLogEntry);
logMsg.add(username,foo);
logMsg.add(eventType,LOGIN_EVENT_TYPE);
logMsg.add(timestamp,12-02-88 17:22:03);
logDaemonConnection.deliver(logMsg);
This would decouple the servers and clients more from the statically
generated stubs (at the cost of a slight overhead). There would still
need be a need for a message definition however it will be transparent
and the client/server do not need to worry about it. The definitions
could come from an external type registry service or from the proto
files.
From what I have read the over-the-wire API deals with things in terms
of tags and I think it should be possible to implement the
functionality I am talking about there.
I would be interested to know what lead to the decision of designing
the system as it stands at the moment. Also I would like to know if
people are interested in a more dynamic messaging API
Regards
Hassan Syed
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
