Background

We've been using github.com/gogo/protobuf for serializing protobuf messages. While it has been working for years, the folks behind gogo/protobuf has recently announced that they are looking for new maintainers and they couldn't catch up with the changes that Google is making on google.golang.org/protobuf.

The situation is causing issues like #62. While we can pin some of the packages from Google to keep them compatible with gogo/protobuf. This workaround may not be sustainable in future.

Options

A. Implement a new code generator that uses mostly Google's official packages

Pros

• Reducing dependencies may reduce the chance of breakage in future.

Cons

• Google's code generator has been using reflection which would be slower than gogo/protobuf. See https://vitess.io/blog/2021-06-03-a-new-protobuf-generator-for-go/ for Vitess' benchmarks.

B. Implement a new code generator that uses utilizes Vitess's vtprotobuf

Pros

• We wouldn't lose gogo/protobuf's fast serialize/deserialize performance.

Cons

• We are replacing gogo/protobuf by planetscale/vtprotobuf. While vtprotobuf would be more maintainable than gogo/protobuf due to the way it extends protobuf, it might break in future.

C. Contribute and possibly own gogo/protobuf

Pros

• We may be able to keep what we have as is.
• We can help others who use gogo/protobuf.

Cons

• We wouldn't be able to keep up with the requests from the protobuf community.
• containerd's usage would not be representative in the community.

D. Looking for non-protobuf solutions

Pros

• We might be able to simplify the wire format.

Cons

• We are making the wire-format change just because we don't like the client library. It may not make much sense.
• Packages like ttrpc-rust has to follow the change.