-
Notifications
You must be signed in to change notification settings - Fork 584
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
Clarify scope of eventID's uniqueness #331
Comments
My take on this was that source + eventID is unique because eventID is unique in the scope of a producer, and the source attribute identifies the producer. With valid DNS-scoped URIs assigned to producers that won't step on each others toes, that is internet-unique. Transient producers could use UUIDs (blech) Applications with lesser requirements can assign source IDs to suit their needs. I'm just getting into the specs tho so may be off track. |
I do not believe
As an example, consider an open-source Change Data Capture project producing cloudevents from actions on a database. The relevant fields might look something like this and be compliant with the current spec:
Even though the project allows distinct source names for many databases with the same For the user, the In my opinion, the conflict introduced by requiring uniqueness in other scopes than the producer-defined one severely diminishes the usability of the spec. The example shows how "unique in the scope of the producer" aptly describes many real-world situations. I am however questioning whether it would be clearer to say " |
@Tapppi thanks for the comment. Right now we say: the ID |
I think the wording needs clarification on 2 points (assuming my reading is correct)
|
I was going to put in a PR but I need to understand the switch from URI to URI-Reference in |
I believe the "context" is "the producer". It's purposely a bit vague to allow for the producer to have the freedom to choose what works best for them and their consumers. |
This is for issue cloudevents#331 Signed-off-by: Alan Conway <aconway@redhat.com>
Attempted to clarify this in PR #391. Goal was not to change the meaning of the spec but just to clarify the uniqueness implications for de-duplication and the meaning of URIs with/without an authority when used as a source. |
The PR contains a description: #338 - the commit does NOT change anything beside the short-hand. It was already a URI-reference. The URI-reference was introduced here: #169
See #169 (comment) TL;DR: The event type gives you the base URI for relative URIs. (But, as pointed out in #331 (comment) , just because the URI is absolute doesn't automatically make it unique. E.g. |
Signed-off-by: Alan Conway <aconway@redhat.com>
is that in the spec? This wasn't my assumption. |
On Wed, Feb 20, 2019 at 2:42 PM Christoph Neijenhuis < ***@***.***> wrote:
I was going to put in a PR but I need to understand the switch from URI to
URI-Reference in
commit 31850e1
<31850e1>
first.
The PR contains a description: #338
<#338> - the commit does NOT
change anything beside the short-hand. It was already a URI-reference.
The URI-reference was introduced here: #169
<#169>
1. The source used to be a URI, but it is now a URI-reference - this seems like a mistake. Only an absolute URI can uniquely identify a source, a relative URI-ref like "db-name/orders/order" is not unique without some absolute URI to resolve it against.
See #169 (comment)
<#169 (comment)>
TL;DR: The event type gives you the base URI for relative URIs.
I'm confused: on current master
https://github.com/cloudevents/spec/blob/master/spec.md#L177 event type is
a String. The spec says it SHOULD be "prefixed" by a reverse-DNS name, but
says nothing about how to reliably parse the type String to transform it
into a URI. I can't find anything that says that "source" and/or
"schemaurl" are supposed to be interpreted relative to the URI so
constructed. If that's the intent it needs to be clarified.
—
… You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#331 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHa6XlWc_vslYEq3--mOF8Rl3yjTMHRIks5vPaUQgaJpZM4XvNd6>
.
|
@duglin I didn't say that - I was pointing to (more or less) the same question that has been asked before, and the answer that was given. Alan wanted to "understand the switch from URI to URI-Reference", and, since I was in the same position a few months ago, I pointed him to the relevant discussion.
Please read Clemens comment in full, my TL;DR is really just a TL;DR 😉 Clemens example of A middleware will not be able to figure out what the correct base URI for
I think so too. The workgroup has agreed to this (before I joined...), and it also took me some time to understand the reasoning behind it. Note to self: Don't attempt to add a TL;DR, it'll do more harm than good 😉 |
Reword "id" uniqueness description. Signed-off-by: Alan Conway <aconway@redhat.com>
Reword "id" uniqueness description. Signed-off-by: Alan Conway <aconway@redhat.com>
…queness. Signed-off-by: Alan Conway <aconway@redhat.com>
Signed-off-by: Alan Conway <aconway@redhat.com>
Signed-off-by: Alan Conway <aconway@redhat.com>
Reword "id" uniqueness description. Signed-off-by: Alan Conway <aconway@redhat.com>
…queness. Signed-off-by: Alan Conway <aconway@redhat.com>
Signed-off-by: Alan Conway <aconway@redhat.com>
Reword "id" uniqueness description. Signed-off-by: Alan Conway <aconway@redhat.com>
…queness. Signed-off-by: Alan Conway <aconway@redhat.com>
Signed-off-by: Alan Conway <aconway@redhat.com>
Reword "id" uniqueness description. Signed-off-by: Alan Conway <aconway@redhat.com>
…queness. Signed-off-by: Alan Conway <aconway@redhat.com>
Signed-off-by: Alan Conway <aconway@redhat.com>
Co-Authored-By: alanconway <aconway@redhat.com> Signed-off-by: Alan Conway <aconway@redhat.com>
Signed-off-by: Alan Conway <aconway@redhat.com>
Reword "id" and "source" to clarify uniqueness requirements. Examples to show different approaches to generating unique source/IDs Clarify producer/consumer responsibilities. Signed-off-by: Alan Conway <aconway@redhat.com>
Reword "id" and "source" to clarify uniqueness requirements. Examples to show different approaches to generating unique source/IDs Clarify producer/consumer responsibilities. Signed-off-by: Alan Conway <aconway@redhat.com>
Reword "id" and "source" to clarify uniqueness requirements. Examples to show different approaches to generating unique source/IDs Clarify producer/consumer responsibilities. Signed-off-by: Alan Conway <aconway@redhat.com>
I'm close to close this because I believe we've address it in the recent PRs we merged about uniqueness. If someone disagrees please speak up and we can reopen. |
On today's call, while discussing #326, it was mentioned that the uniqueness statement in eventID might need some clarity. Right now the spec says that it:
MUST be unique within the scope of the producer
but what constitutes the "producer" could vary and there was a discussion around how combining thesource
andeventID
properties should produce a globally unique value - but the spec doesn't say this. We should decide what kind of clarity we want to add around this - if any.The text was updated successfully, but these errors were encountered: