Support different serialization and deserialization names for `JsonNamingStrategy`

[Dogacel]

What is your use-case and why do you need this feature?

Protobuf JSON format specifies,

Proto3 JSON parsers are required to accept both the converted lowerCamelCase name and the proto field name.

Thus we need to support reading snake case and write as camelCase. We can actually use JsonNames(...) for this but I believe it will be really inefficient to write this for each class every time.

Source: https://protobuf.dev/programming-guides/proto3/#json

Describe the solution you'd like

I am trying to create a preset of Json serializer that serializes Protobuf compliant

So there are two options:

1. Configure existing Json serializer to work with protobuf
2. Create a new StringFormat that is called ProtoBufJson

I am trying to do the second because it seems easier to start with.

What are your thoughts? Do you think adding this ProtoBufJson as default makes sense? If not, I can start working on the project as a separate repo.

[pdvrieze]

So you basically want to support the transformation between json and protobuf according to the protobuf standard? That transformation can be supported by the parsing/generation part of the serialization library, but isn't quite the same as serialization.

A separate part could be that you may want to support serialization with a variant of Json that is compatible with being used as if it was the json mapping of protobuf (thus this variant should support protobuf specific annotations etc.). I would say a separate format is the way to go, as it would also need to ignore a lot of what the json format has in configuration (as that wouldn't match to protobuf).

[Dogacel]

So you basically want to support the transformation between json and protobuf according to the protobuf standard? That transformation can be supported by the parsing/generation part of the serialization library, but isn't quite the same as serialization.

A separate part could be that you may want to support serialization with a variant of Json that is compatible with being used as if it was the json mapping of protobuf (thus this variant should support protobuf specific annotations etc.). I would say a separate format is the way to go, as it would also need to ignore a lot of what the json format has in configuration (as that wouldn't match to protobuf).

I did not thought about that, that's right. I think there should be a separate ProtoBufJson object that serializes to proto-json string. It might still use Json underneath.