Eiffel on Cloud Events

[m-linner-ericsson]

Applicable Issues

Fixes #399

Description of the Change

Adding a description on how to bind Eiffel to Cloud Events

Alternate Designs

This PR discusses two different options on how to set the type, see text

Possible Drawbacks

Opening up possibilities for sending Eiffel events on over other transport protocols than AMQP might give some light of not having just one way of doing things.

Sign-off

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

Signed-off-by: Mattias Linnér [email protected]

[e-backmark-ericsson]

I really like that this idea of binding Eiffel on to CloudEvents is now getting some realization! Thanks @m-linner-ericsson !

Regarding the alternatives on the type field, I believe the reason for CloudEvents strongly recommending a reverse dns name as a prefix is to make the event type unique across different event 'protocols' (different data payload structures). Therefore I'd recommend we go for such a syntax on the type field. We could consider to make it all lower case, potentially prefixing internal capital letters with hyphen or underscore before the corresponding lowercase letter.

Furthermore I believe we should add the optional dataschema field to the cloudevent part, giving it the same content as our meta.schemaUri

[m-linner-ericsson]

I really like that this idea of binding Eiffel on to CloudEvents is now getting some realization! Thanks @m-linner-ericsson !

Regarding the alternatives on the type field, I believe the reason for CloudEvents strongly recommending a reverse dns name as a prefix is to make the event type unique across different event 'protocols' (different data payload structures). Therefore I'd recommend we go for such a syntax on the type field. We could consider to make it all lower case, potentially prefixing internal capital letters with hyphen or underscore before the corresponding lowercase letter.

Furthermore I believe we should add the optional dataschema field to the cloudevent part, giving it the same content as our meta.schemaUri

Good points, fixed that in 0f248f6

[magnusbaeck]

Yes, I definitely think we should use the recommended reverse DNS pattern for the type. Too bad we don't have a real domain for Eiffel.

[magnusbaeck]

LGTM content-wise, but we should link to it from README.md.

[m-linner-ericsson]

LGTM content-wise, but we should link to it from README.md.

Thanks Magnus! Fixed in be351d1