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
-~----------~----~----~----~------~----~------~--~---
