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

Reply via email to