-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add protobuf schema support #721
Comments
Why not store and present as the schema as json form e.g. like .proto files, it would then be more align with how we are doing avro using a json form to store the schema and more consumable. |
There is some complexity to add to client side, to support dynamically registering by capturing the schema from the generic message. Not both apicur.io and confluent schema registry in adding support there have achieved this so can be used as point of reference. Also should ensure that as like done with avro, the confluent compatibility layer should be extended to support protobuf |
I agree that taking JSON representation of proto3 ( btw, this is only for proto3 i think) would simplify things. but problem is user would require utility convert proto to JSON and its not very straight forward without going through proto parser and bunch of other things. |
Go look at confluents code its there, also theres a jsonformatter in proto ;) |
Sure, json formatter is from proto lib so we definitely plan to use that for JSON -> proto_descriptor -> JSON. but i also wanted to provide proto_IDL -> proto_descriptor -> (proto_IDL or JSON or XML) |
Also remember will need client side support. And obviously the key bit would be to auto register a Message (as like avro) where it gets the schema from the object. And for DynamicMessage support, so an app can take the schema from registry and process the message without needing precompiled. |
Lastly something to think about. Is that its actually possible to convert a protobuf to avro (and likewise schema) it be good to support that in registry. E.g use case would be a microservice world using predominant protobuf e.g. grpc or classical messaging, where then you want to ingest all that into kafka and larger data system thats all working in avro |
+1, the idea for protobuf -> avro sounds cool. will try that once we have initial protobuf support that we are planning for ( as you described in ur first comment ). Thanks for the help in making the feature better. |
We should add protobuf schema support in the schema registry.
Here is what we are thinking this would include:
required changes as heads up:
Please provide comments if you have any.
The text was updated successfully, but these errors were encountered: