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 >
