-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Setup SourceUnit interface #1393
Conversation
// SourceUnitUnmarshaller defines an optional interface a Source can implement | ||
// to support units coming from an external source. | ||
type SourceUnitUnmarshaller interface { | ||
UnmarshalSourceUnit(data []byte) (SourceUnit, error) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since these returned SourceUnit
objects will be opaque to callers, how do they get used? Will they just be sent back to the source to either marshal or consume?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, most likely they'll be provided to the caller to be consumed. Marshalling can happen without the Source
doing it for us.
It's an extra step the engine will have to take to scan units marshalled and stored in an external source.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
per huddle: they won't be completely opaque, because the source unit manager will be recording each source unit's id and using it to plan/report on things
This sets up the interfaces for sources to begin supporting enumeration/scanning with
SourceUnit
s.For example usage, see this commit.