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