-
Notifications
You must be signed in to change notification settings - Fork 630
Improve EventType Registry #2750
Copy link
Copy link
Closed
Labels
area/eventingThe Eventing api groupThe Eventing api groupkind/feature-requestpriority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.Important over the long term, but may not be staffed and/or may need multiple releases to complete.triage/acceptedIssues which should be fixed (post-triage)Issues which should be fixed (post-triage)
Milestone
Metadata
Metadata
Assignees
Labels
area/eventingThe Eventing api groupThe Eventing api groupkind/feature-requestpriority/important-longtermImportant over the long term, but may not be staffed and/or may need multiple releases to complete.Important over the long term, but may not be staffed and/or may need multiple releases to complete.triage/acceptedIssues which should be fixed (post-triage)Issues which should be fixed (post-triage)
Type
Projects
Status
✅ Done
Problem
EventType is tightly coupled with Broker. In fact, it has a
brokerattribute in itsspec. We should decouple EventType from it.The EventType registry itself should be "autonomous", while other constructs (e.g., brokers, channels) should be able to refer to it (ack @markfisher )
This idea has been floating around for a while now, probably since the EventType registry inception (ack @n3wscott).
We should also probably add few more things to it, such as available extensions an EventType can produce, etc. Still TBD.
Creating this issue separately from #2484, which mainly refers to improving the current implementation.
Persona:
Which persona is this feature for?
Developer
Exit Criteria
A decoupled EventType registry, "queryable" from different constructs
Time Estimate (optional):
infinite
Additional context (optional)
#2484 for some initial proposals there...
/cc @vaikas @mikehelmick @n3wscott @mattmoor @grantr @lionelvillard @markfisher , etc, etc...