search

cloudevents / spec

CloudEvents Specification
https://cloudevents.io
Apache License 2.0
5.07k stars 583 forks source link

Disambiguation/clarification of source/source-id/source-type #94

Closed clemensv closed 6 years ago

clemensv commented 6 years ago

The "source" property is, irrespective of being interpreted as a URI or URL, already an identifier for the source itself. The "source-id" therefore appears superfluous.

However, the present schema does not provide any further context qualification for the event relative to the source, so I am proposing to repurpose the source-id to provide that context qualification. In common messaging APIs and protocols (including the emails stack), the qualification property is called "subject".

Furthermore, with "source" already being a structured identifier (URI) and the event being sufficiently qualified by namespace/event-type and the subject, I question the practical value of the "source-type" property and propose for it to be removed.

Assigned to: @clemensv

ultrasaurus commented 6 years ago

I don't really understand the problem you are trying to solve. I'm having trouble following this series of recommendations, since I'm hearing a critique without a clear statement of how the set of attributes are used together and for what use cases.

(This was an issue with the spec before @clemensv arrived, and I really appreciate the focus on detail -- I just want to make sure everyone is aligned on the big picture)

yaronha commented 6 years ago

@clemensv @ultrasaurus i think we only need a single source field which calls out the entity or a proxy which pushed the cloud event, additional source info can be found in the schema. e.g. if there is an S3/Blob update event the source need to be the s3 service, and the source S3 object which pushed the event needs to be in the message body along with other "sources" (users, location, ..). we must keep CloudEvents simple, metadata only describes the "envelop" not the Message itself. dont want us to become yet another Soap/XML/..

ultrasaurus commented 6 years ago

please see note in issue #82 -- I have the same concern with all of the separate source issues

duglin commented 6 years ago

@clemensv do you think we can close this one now?

duglin commented 6 years ago

tagging as "GoingToClose" - so speak before EOD tomorrow if you think we should keep this open

duglin commented 6 years ago

Closing per WG agreement