Move to a custom protobuf code generator #78

New issue

Open

opened 2024-04-26 10:16:36 +00:00 by fyrchik · 1 comment

fyrchik commented

2024-04-26 10:16:36 +00:00

Owner

The following migration plan is proposed:

Merge #77, which generates the same structures as native protobuf (+ private messageData field), albeit with a different set of methods (easyproto for protobuf marshaling, easyjson for JSON marshaling).
Use MessageData methods for checking signature in the frostfs-node.
Gradually alter struct representation: replace []*T with []T and do not use pointers for message fields (we might need some settings here).
Remove old stable marshaler generator artifacts (use ToGRPCMessage().EmitProtobuf). May be done in parallel with (3).
Make types in object/ etc. aliases to object/grpc/. Most conversion functions become a no-op.
Completely remove the second wrapper level.

Addresses #40
#66 becomes trivial, we might easily add accessor methods with easyproto.
#39 becomes somewhat irrelevant, because we no longer need to marshal the message multiple times.

The following migration plan is proposed: 1. Merge #77, which generates the same structures as native protobuf (+ private messageData field), albeit with a different set of methods (easyproto for protobuf marshaling, easyjson for JSON marshaling). 2. Use `MessageData` methods for checking signature in the frostfs-node. 3. Gradually alter struct representation: replace `[]*T` with `[]T` and do not use pointers for message fields (we might need some settings here). 4. Remove old stable marshaler generator artifacts (use `ToGRPCMessage().EmitProtobuf`). May be done in parallel with (3). 5. Make types in `object/` etc. aliases to `object/grpc/`. Most conversion functions become a no-op. 6. Completely remove the second wrapper level. Addresses #40 #66 becomes trivial, we might easily add accessor methods with easyproto. #39 becomes somewhat irrelevant, because we no longer need to marshal the message multiple times.