Source as a URI#123
Conversation
Signed-off-by: Doug Davis <dug@us.ibm.com>
|
@dug LGTM |
|
👍 |
|
I just closed #95 in support of this PR. This simplification does align with what we believe we need for addressing our customers' needs. We will have optimization comments subsequent to this PR. |
|
Agree with @clemensv .. My only (minor) concern would be that we should type 'source' as a string instead of a URI since we're consolidating namespace into it as well. The format (which is yet to be determined) may or may not take the form of a URI, but we can't make that distinction yet. |
|
I thought about that but I remembered that when I casually mentioned it as a string on a call a long time ago some folks pushed back, so I picked URI as the starting point. Would you be ok with discussing a possible re-typing in a follow-on PR? |
|
@duglin That's reasonable. I like the consolidation, so long as we agree that a follow-on PR may (or may not) change the format of 'source'. |
mrutkows
left a comment
mrutkows
left a comment
There was a problem hiding this comment.
LGTM. Wherever we can avoid String generalizations for identifying (well-formed) URIs is a very good thing IMO.
|
LGTM |
|
LGTM |
|
I don't want to let great be the enemy of good. I will ask in the future that we specify some subset of URI to build APIs on top of this (e.g. one that includes an authority), though URIs LGTM. |
|
LGTM |
|
LGTM |
|
Approved on 3/29 call. |
12 participants
In an attempt to get to a MVP for the spec, I'm proposing to collapse source-related attributes (source* & namespace) down to a single URI whose format/encoding is event producer defined.
Future PRs can suggest that we split out certain bits of data from this URI (e.g. for performance, optimization or other reasons), but then those discussions will be more focused on just the specific need being addressed, so hopefully will be easier to reach a consensus.
Signed-off-by: Doug Davis dug@us.ibm.com