Skip to content
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

Review Data Model (Protos) #11

Closed
tedsuo opened this issue Apr 17, 2019 · 9 comments
Closed

Review Data Model (Protos) #11

tedsuo opened this issue Apr 17, 2019 · 9 comments

Comments

@tedsuo
Copy link
Contributor

tedsuo commented Apr 17, 2019

Everyone, please review the current protobuf and metadata definitions and leave comments here.

@tedsuo
Copy link
Contributor Author

tedsuo commented Apr 26, 2019

@bg451
Copy link
Member

bg451 commented May 8, 2019

I chatted with @iredelmeier about the model and a concern about using protobuf came up.

If a language does not support protobuf or a user doesn't want to include the protobuf library due to size (e.g. browser javascript), there needs to be a common way to serialize spans and metrics using something like JSON. Clear mappings to JSON exist for most protobuf types, however, the protobuf definitions in the SDK heavily uses oneof which do not have defined mappings to JSON. See the protobuf JSON reference for what is and isn't defined. I think this is something that should be discussed when the protos are moved to their own repo.

@yurishkuro
Copy link
Member

@bg451 good point, and it's not just JSON, in some languages mapping oneof to types is exceptionally ugly. In Jaeger protos we decided to live with minor possible ambiguities of the data rather than have to deal with oneof.

@bogdandrutu
Copy link
Member

I think the oneof implementation is as simple as in the JSON you enforce to send only one of these fields. I may be wrong but I can ask.

@bogdandrutu bogdandrutu transferred this issue from open-telemetry/opentelemetry-java May 31, 2019
@tmc
Copy link

tmc commented Aug 29, 2019

It's a bit unfortunate that there isn't a great way to attach structured nested metadata as attributes. Perhaps consider supporting Any values as a means of extension?

@bogdandrutu
Copy link
Member

@tmc we discuss to add some support of AttributeValue to be another Map<String, AttributeValue> is that enough?

We do not want to add Any because that means that a backend cannot analyze the data, maybe not even display them.

@tmc
Copy link

tmc commented Aug 30, 2019

I imagine that for many use cases allowing maps would suffice.

@tete17
Copy link

tete17 commented Sep 9, 2019

Sorry to step into this conversation but is the idea of this project that all other language implementations to use this definition as a basis of is it only for the Java one?

I do not see it in use as a submodule for the node-js one

@SergeyKanzhelev
Copy link
Member

Seems to be complete. See open-telemetry/oteps#59 where we extensively reviewed it.

Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants