Just to be more precise: the overall goal is, that the messagetype
identification stuff should be managed entirely in the proto files. the
user should only be concerned to write his handlers and the network
protocol definitions.
Original Message
Subject: Detecting message type
Not 100% on-topic, but: is there any special reason why the code
generator for .NET needs to be written in .NET itself? The Java
generator isn't written in Java, after all. We've been using
Jon's .NET library, and we just copy-and-pasted the standard Java
generator and made a C# generator for
Not 100% on-topic, but: is there any special reason why the code
generator for .NET needs to be written in .NET itself? The Java
generator isn't written in Java, after all. We've been using
Jon's .NET library, and we just copy-and-pasted the standard Java
generator and made a C# generator for
Not really, except for convenience; and actually, most of the code-gen
in this case is actually done in xslt, not directly in .NET (protogen
is very shallow in terms of what it does; most of the code is parsing
command-line inputs... it only looks fat because it contains an
embedded copy of
How about using extensions to solve this? You could define a generic
message:
message Packet {
extensions n to m;
}
// Payload messages
message TestMessage {
extend Packet {
optional TestMessage test = 10;
}
required string msg = 2;
}
message TestMessage2 {
extend Packet {
By the way you may want to look at the section on Union Types in the
docs: http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
On Jul 21, 9:51 am, jasonh jas...@google.com wrote:
How about using extensions to solve this? You could define a generic
message:
message Packet {
