Scenarios:

1. enable usage similar to protoc --decode to walk a payload+schema and understand the contents
2. enable weak object-model usage, i.e. payload+schema to dynamic or similar, ideally in a way that is usable from other common serializers, for example as a transcoder
3. act as a backbone for any other schema+payload scenarios without the implementor needing to do all the thinking

Currently this is implemented via:

• DecodeVisitor - has the logic to iterate over a payload while tracking a schema
• TextDecodeVisitor : DecodeVisitor - provides a protoc --decode style raw text dump of the interpreted payload contents
• ObjectDecodeVisitor : DecodeVisitor - provides an ExpandoObject-based object-model from the interpreted payload

Work items:

• basic command-line hooks into protogen (global tool)
• implement base visitor that processes fields via a parser
• implement text visitor (i.e. stdout) for output
• implement object-model visitor
• documentation (at a minimum, for -h and ///; a new page under /docs would be good too, though)
• basic unit test
• comprehensive unit tests
• validation of command-line usage (rather than library usage)
• comparison to protoc output
• well known types (.google.protobuf.Duration, .google.protobuf.Timestamp, for example)
• types with special expected formatting (.google.protobuf.Timestamp, for example) (note: this might not apply if we get the well-known-types support to map to regular .NET types that already have the correct handling)
  • in particular, struct.proto and wrappers.proto
• how should enums be represented in ObjectDecodeVisitor? currently uses int, but: is that right? should it be an option on the object, i.e. new ObjectDecodeVisitor { Enums = EnumMode.Name } ? (which would presumably use the name when possible, and the integer as fallback) - Google lib writes names, reads either names or integers
• support for packed primitive values (note this is based on reader.WireType being String for a primitive value (i.e. not string, bytes, group or message) and not on anything related to field)
• consideration of extension fields; i.e. should we try to discover known extended field definitions, and present them sensibly?
• what output (if any) for unknown fields?
• need to detect and implement map scenarios
• ObjectDecodeVisitor: default values and presence tracking; i.e. in proto3 a non-presence-tracked field with value zero/false/etc is not transmitted, but that is still the expected value (if it is presence-tracked, then it is transmitted if assigned)
• ObjectDecodeVisitor: option to use json_name rather than name (when json_name specified)
• naming; are the names correct? ObjectDecodeVisitor seems... weird