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

Add Event and TimedEvent #73

Merged
merged 15 commits into from
Jul 8, 2019

Conversation

danielkhan
Copy link
Contributor

This adds a type for Event and TimedEvent needed for SpanData.

* Represents a timed event.
* A timed event is an event with a timestamp.
*/
export interface TimedEvent {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the motivation for making Event and TimedEvent distinct? Is that specified in the spec?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not explicitly. Here's the spec that mentions them and here is the Java implementation.

A timed event has a timestamp attached to it, so to me, it makes sense to create a type for it and I think that was also the reason why Java does it like that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there needs to be a distinction. An event always has a time. This is a fact not only in software but also in the physical world.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Event does not have a time and there is a TimedEvent in the spec. I think that we should stick to the spec and discuss and deviation from it with the spec team.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are so many things wrong with the spec that I don't think this is the best approach.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I am confused why there would be an event with no time, seems like a leftover from opencensus's implementation that ended up in the API.

@mayurkale22
Copy link
Member

@danielkhan The Event interface has already been addressed in PR #63. Could you please review ?

@danielkhan
Copy link
Contributor Author

@danielkhan The Event interface has already been addressed in PR #63. Could you please review ?

I missed that one. Done. I'll wait for this to be merged and modify my PR then.

@draffensperger
Copy link
Contributor

Could we do something like this:

interface Event {
  name: string;
  attributes: Attributes;
}
interface TimeEvent extends Event {
  time: number;
}

?

That would allows the events to be simple structures and the interfaces could show a relationship between the two.

Could we always use TimeEvent in the actual implementation, in which case the Event could just exist as a nod to the spec? Or are there cases where we would actually want an Event without a time?

@danielkhan
Copy link
Contributor Author

Changed the types to extend Event to create a TimedEvent

@rochdev
Copy link
Member

rochdev commented Jul 5, 2019

Actually I think I understand the rationale. If I'm not mistaken, Event would allow you to create the TimedEvent (which is the real event). Basically you pass an Event to some kind of event builder that will create the actual TimedEvent for you with the proper timestamp.

This would not be an issue if the API was designed differently, but unfortunately that is not the case right now.

Copy link
Member

@rochdev rochdev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

File naming is inconsistent with the rest of the project.

@danielkhan
Copy link
Contributor Author

File naming is inconsistent with the rest of the project.

Please suggest because as far as I can see, there are still discussions and the project is inconsistent. Can we merge and sort that out with #38?

@codecov-io
Copy link

codecov-io commented Jul 8, 2019

Codecov Report

Merging #73 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #73   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          10     10           
  Lines         152    198   +46     
  Branches        8      8           
=====================================
+ Hits          152    198   +46
Impacted Files Coverage Δ
test/trace/tracestate.test.ts 100% <0%> (ø) ⬆️
test/trace/ProbabilitySampler.test.ts 100% <0%> (ø) ⬆️
test/resources/resource.test.ts 100% <0%> (ø) ⬆️
src/common/util/id.ts 100% <0%> (ø) ⬆️
test/common/util.id.test.ts 100% <0%> (ø) ⬆️
test/trace/NoopSpan.test.ts 100% <0%> (ø) ⬆️

@danielkhan danielkhan merged commit ca9641f into open-telemetry:master Jul 8, 2019
dyladan added a commit to dyladan/opentelemetry-js that referenced this pull request Sep 9, 2022
* chore: 0.19.0 proposal

* revert global API symbol key
dyladan added a commit to dyladan/opentelemetry-js that referenced this pull request Sep 9, 2022
* chore: 0.19.0 proposal

* revert global API symbol key
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

Successfully merging this pull request may close these issues.

None yet

6 participants