Create primer

[manuelottlik]

Before creating a PR with the full text, I wanted to collect some bullet points and get your ideas. This is how I would approach this Primer:

• CloudEvents are harmonizing different event structures and increase interoperability, but they do not provide an answer to the following questions:

  • Where can I produce / consume events? What endpoints exist?
  • How can I validate events?
  • How can I version events - and see which versions exist?
  • If I specified extensions – how can I know which events are using which extensions?

• There are many schema registries out there, like:

  • Confluent Schema Registry, Azure Event Hubs Registry, Apicurio Registry, Solace..

• If an event travels through multiple brokers, it's schema has to be introduced in the registry of each broker. Thanks to CloudEvents the schema stays identical and is quite independent from the broker & protocol, but clients still have to mind the implementation differences between the different registries per broker.

  • e.g. if they are trying to validate an event

• xRegistry therefore comes in with a similar motivation as CloudEvents: Harmonize another piece of technology in the messaging / eventing ecosystem to increase interoperability and detach event handling from broker products and protocols.

• xRegistry stands for extensible registry and in its core provides metadata about resources. That does not only sound very abstract, it actually is hence its extensibility.

• As an example, you could have endpoints, message definitions and schemas.

  • I would then go on and showcase how this sample registry would solve the questions I raised in the beginning before making a transition to the spec.

I vaguely remember someone saying that the motivation behind xRegistry was not only to describe CloudEvents but that you had a broader use case in mind, I do not remember which one that was though. So if there are key points missing to this narrative, please mention them in the comments.

[manuelottlik]

• You do not have to use CloudEvents: List other formats, schemas, protocols etc
• You can generate stuff: CLI, OpenAPI, AsyncAPI
• The core spec has nothing to do with eventing (we are biased and focussed on it, but its not used only for that)
• List three evolutions: file, S3, API
• Use Case:
  • well known place in repos that is the entry point for metadata files like package.json etc
  • in a machine readable way