Devin, thanks for bringing up this discussion. I have one high level question: what is the goal that we want to achieve ? something like: 1) Use CloudEvents format natively in Pulsar Schema registry, so that Pulsar clients can register their schema using that format 2) Publish on some HTTP endpoint the Schemas saved in the Pulsar Schema Registry in a way that non-Pulsar clients (like WebServices) can consume Pulsar messages 3) other
I agree that supporting CloudEvents would be great in Pulsar and we should do something. If you have a real world use case to share we can start by that use case, that will help a lot Enrico Il giorno lun 5 set 2022 alle ore 18:07 Devin Bost <devin.b...@gmail.com> ha scritto: > > Maybe this is something we could discuss as part of Pulsar 3.0? > Seems like there's a pretty big difference between SchemaInfo and > CloudEvents in terms of the fields. > > CloudEvents requires: > id: String > source: URI-reference > specversion: String > type: String > > and optionally: > datacontenttype: String > dataschema: URI (compliant with JSON Schema specification 07) > subject: String > time: Timestamp > > For JSON, CloudEvents uses the JSON Schema spec for validation. > > In contrast, Pulsar's SchemaInfo has: > name: String > schema: byte[] > type: SchemaType > properties: Map<String, String> > propertiesSet: bool > timestamp: long > > > -- > Devin Bost > Sent from mobile > Cell: 801-400-4602 > > On Fri, Sep 2, 2022, 5:33 PM Devin Bost <devin.b...@gmail.com> wrote: > > > Hi recently discovered the discussion around creating a CloudEvent binding > > for Pulsar. https://github.com/cloudevents/spec/pull/237 > > > > It appears that Pulsar doesn't meet their minimum requirements due to lack > > of a standard protocol. See https://github.com/cloudevents/spec/pull/254 > > > > Their comment says: > > > > "For a protocol or encoding to qualify for a core CloudEvents event format > > or protocol binding, it must belong to either one of the following > > categories: > > - The protocol has a formal status as a standard with a widely-recognized > > multi-vendor protocol standardization body (e.g. W3C, IETF, OASIS, ISO) > > - The protocol has a "de-facto standard" status for its ecosystem category > > which means it is used so widely that it is considered a standard for a > > given application. Practically, we would like to see at least one open > > source implementation and at least a dozen independent vendors using it in > > their products/services. " > > > > As CloudEvents is gaining momentum within CNCF, this may become a problem. > > > > Has their been any discussion around standardization and how we might meet > > this requirement? > > > > -- > > Devin Bost > > Sent from mobile > > Cell: 801-400-4602 > >
