Add Polymorphism architecture description for Protobuf into readme file

[EMaksymenko]

There are missed information on how Protobuf plugin implements serializing sub-classes into byte array in the user manual.
You have described ProtoNumber annotation usage but omit description of type field numbering and how to control it.

My use case is:
I need to accept byte array on other external system (Kotlin incompatible) using generic Proto file declaration approach.
I need to understand all aspects of field numbering to build similar Proto file with the same field numbers.

All custom fields can be annotated with ProtoNumber, but what about polymorphism type field?

[EMaksymenko]

As I revers engineered polymorphic properties stored in wrappers with fields:
string type = 1
bytes value = 2

[rotilho]

I've been following the discussion on this issue and was wondering if there has been any progress on adding the polymorphism docs for Protobuf. Additionally, I've noticed that the SerialName appears to be serialized as a string. Is this the intended behavior, and if so, could this be documented as well?

[sandwwraith]

Yes, the serial name is always a string.

[rotilho]

Are there any plans to add something like @ProtoSerialNumber?

[sandwwraith]

@rotilho There is @ProtoNumber for fields. Polymorphism, on the other hand, requires class (not field) serial name to deserialize a correct subclass.

[pdvrieze]

@rotilho For clarity. The "key"/type for polymorphic serialization is always the serial name of the instance type. If you put an @SerialName annotation on it, the value used is that of that annotation, otherwise it is the fully qualified class name. (And yes if you have duplicate names, that can confuse formats & polymorphic serialization).

[rotilho]

Thanks, @pdvrieze. I'm still not able to see the schema generated due to #2089, but this was my understanding based on the bytes generated (there are still a few bytes I didn't understand, though).

I have a very specific use case where thousands of very small messages will be exchanged per second. My initial expectation was that kotlinx-serialization would use the oneof and each type would have a different number, which is perfect for my use case. Encoding SerialName significantly increases the message size.

[pdvrieze]

Unfortunately the protobuf format doesn't have such special support for polymorphic types. It might be possible to create your own format variant that does, but you want to have stable ids (too easy to have automatic ids for types change).

As to the format, I would go for delegating to the protobuf format, but handling polymorphic children differently.