Looking forward to this PR, and would love to help implement. Is there a slack/discord/forum for discussion anywhere?

I was in a bit of a time crunch on a current project and did not realize this library did not support Protobuf formatted messages. In order to get around it for now we ignore SchemaRegistry, precompiled the protobufs, and then had to strip out the Magic Byte and other SchemaRegistry headers, but it does decode now. Obviously this is not ideal and kills the purpose of SchemaRegistry, so the sooner I can fix the better.

I am curious how you would implement this, I am not 100% sure how the Confluent deserializers operate behind the scenes. Are they compiling the Protobufs on the fly, caching, dynamically load the classes after with reflection?

I am planning on separating these concerns. On the HTTP side the only thing we need is a schema type and a string representation of a given schema.

The hard part is that I would need to change the Registry interface to not return an AvroSchema, but a more general Schema that contains the type and the string representation so that downstream clients can make decisions on what to do with it.

There are multiple options that are currently in my head:

One Regisitry interface and a generic Schema representation

This is currently my preferred option. The HTTP side is very easily changed, and internally it would just build a generic Schema with a SchemaType and a string schema. I don't think that validation is necessary here, this concern should be handled further downstream.

Multiple Registry interfaces

We would have AvroRegistry, ProtoBufRegistry and JsonRegistry interfaces and downstream clients can inject there relevant implementations. This library would provide default implementations. While this is possible, it makes the general usage of this library more complicated.

Others?

I am open for suggestions, I started the SchemaType implementation on the issues/41 branch:
https://github.com/flix-tech/schema-registry-php-client/tree/issues/41/src/Schemas