Joshua Humphries

I totally understand not wanting to fork. (I made the same appeal to the protobuf project.) I just hesitate to make this repo the home for that. That being said,...

@richardartoul, I think I may be flip-flopping regarding a public API for the binary protobuf format. I now have need for something similar, too, outside of this repo. So I'm...

I'm afraid I have no intention of changing this right now. This package was built on top of the v1 API of the protobuf runtime, which are the packages in...

@btiernay, sorry I never replied to that last comment. You can easily convert between the V1 and V2 message types using helper functions in the `proto` package of the V1...

This is expected because the range of a 64-bit integer is not necessarily representable by JSON numbers (which are typically interpreted as 64-bit _floats_, so they cannot accurately represent all...

I don't see a compelling reason why this dynamic message package should provide different/more JSON marshaling capabilities than the main protobuf runtime. Sorry.

I'm going to assume the `-` lines are `protoparse` and the `+` lines are `protoc`? In the future, it would helpful to include information like that. Also, a diff of...

FWIW, it is not always expected that `protoparse` provide a byte-for-byte match with `protoc` in the descriptors. There are several other edge cases where things like serialization order of fields...

Interesting and super-weird that `protoc` adds an empty value to the map entry. I had assumed that side would have been `protoparse` (like an artifact of how the Go protobuf...

Ugh, looks like `protoc` must have some gnarly parsing logic to identify fields that look the same this way :/ It considers all of these to be conflicts, too: *...