 All right, let's see what time is it one o'clock. Hopefully we'll have a few more people Looks like Doug just joined Mark's here Carol's here. So we have Carol and Mark from VMware and the dispatch project Doug the infamous Doug from IBM and our leader of the serverless working group and Simon. I'm not sure Hey, hey Simon, you want to do a brief intro Yeah, hi. And so I work for Red Hat. I've been working with Matthias Westendorf, who's been a bit more engaged with this group than I have Sat in on the last call when I was with a face-to-face with Matthias. Matthias is on vacation today and for the next two weeks. So So I want to sit in and sort of contribute where I can do, although I've largely been talking about the work that he's been doing Putting a Java API and a couple of different implementations of the cloud events back together Cool Fantastic great to have you and Matthias and everyone over at Red Hat Um, let's just go ahead and get started with the people who are in the call now I'm going to do a quick recap since it was almost a month ago that we did that we had our last meeting In our last meeting, that was our first conversation around designing SDKs for cloud events What prompted that specific conversation was the fact that hey, we came out with this great specification for a common envelope for event data The next step, however, is to actually make it easy to put in the hands of developers by building some SDKs Um, it was we realized after some conversations on the working group call that a lot of people were already making SDKs And we were kind of doing it in an informal Siloed way and we said, okay It's clear we should have a conversation about this to see if we could kind of align all of our implementations on some common goals Uh, hence that that inspired the first call Uh in that first call, which was on june 25th. We drafted use cases features goals for the cloud events SDK and then we ranked them all by priority Um, and then we organized all those priorities into SDK versions and created a bit of an informal roadmap And then we found some volunteers for implementations across a few languages that we'd like to target We took that progress reported it to the cncf serverless working group They said great it looks great and uh, but it's up to us to actually like deliver something And I think we're we're getting pretty close right now. So so hopefully on this call. I was thinking I drafted I drafted a brief initiative here and I put it in this cloud events design proposal google document and It looks like we've already Pasted this in the In the chat room. Yeah, I think binary did do the link is the is the notes Not for the agenda. They did the note note taking Cool. Well, yeah, we have been working off this cloud events SDK design proposal google document At the very top. I've drafted pretty lean loose agenda For this conversation. We should chat about it real quick in case anyone has any other ideas, but I'll Read it as is I figured let's let's go ahead and check in. Let's see if people, you know, we drafted out some priorities and Targeted a scope of work for versions 0.1 of this SDK and I think some people have made some progress. So we should share our progress See see what people have made and you know, it'd be great to share some problems or some learnings along the way Um, and from there, I think we should after we hear what you know What people have done and where some problem areas are and where some ambiguity is Let's identify areas that we need to clarify to clarify further together And hopefully achieve greater alignment as a result And then after that, it seems like if it seems like we have some cloud event SDK implementations that are almost ready to go As is or they might just be very very close to being ready to go I think it's time to discuss publishing these to the cloud events github org And dug is on the line ready to handle all of uh, all of our questions about how we're going to go Go about doing that. So that's the agenda written as is. Does anyone have any suggestions or ideas for other agenda topics that we should discuss on this call Go at once go in twice All right, let's do this. Let's go ahead and check in with each other and review progress I was just chatting with carol about the VMware dispatch cruise progress on doing a cloud events SDK implementation is go in go and Maybe we'll start with you carol since you're already all warmed up. Sure. Thanks. Let's go how it's going Share problems, you know questions you have and of course like one of the Bleeding from the neck problems that you need to have clarity on So that you can move forward with the implementation and any interesting thing that you've learned Oh, of course, of course. So I've been I've been looking at You know, there's a lot of existing go code for cloud events for version zero one that was For example, people worked on for the demo That was at the cube con. So I've been looking how how is this being used in different projects I'm trying to extract the common layer because of course we we also use cloud events in this batch so the The repo that we created and then I posted to the sdk ticket will include This work I've pushed some code Uh, I would say the minimum version of of the event that Is currently supported It implements the basic spec the basic structure of the event and Http bindings. I think this is the bear that like the minimum That that I could do now. I think that the the there will be a lot of work to support Custom continent coding and decoding. Um, I imagine that we would like to support some some some sort of Encoders registry But I'm curious what's what's the approach for all the languages right now. I only support Jason Since this is the the most it seems to be the most common format And that everybody uses of course, there's a binary and structured mode defined by http binding So this so this is easy to support because it's it's it's defined there But I'm sure there will be a lot of Um, the a lot of the formats that people would like to use that are not Broadly supported or super popular But still people people would like to to use So I imagine there will be some sort of a registry that The users of sdk could register custom encoders and decoders for different content types Um with regards to things that I've learned while working on that Um My initial goal was to To create a some sort of an interface that would be it will help That I thought would be good to to to you know Survive different versions of the spec right so there's a there's a this discussion about Removing the extensions back from the from the spec and have the extensions to be a top level attributes of the of the event of the event context And I was trying to think what would be the The interface that could handle that right? What would be the interface that could work the same way with without with extension back and without I know that doc has some json has some work to to Deal with with this in uh json format What happens when you have extensions uh in the in the separate Attribute and what happens when they're a top level? Um So I was thinking like what would be what would happen if there was a general like a generic getter and setter for those attributes Right, but then you lose the the type safety because if it's generic then in go at least you need to do some some You know unscoped interfaces that that require that are not type safe Or you you need to do some The type checking at the runtime. So this this this is a I see this as one of the pain points in the future Um, so right now my work is to just address the the version zero one Uh prepare my my goal is to have you know the the interface or the api that works with version zero one um and Have this you know Addressed have this being tested in different use cases. So have this work with the dispatch. Hopefully Work the same way in all the use cases that I see already Uh have tests for that and then see if we can You know create a bulletproof interface for future. I don't think we can avoid breaking changes Forever because this is never a case, but hopefully the interface Would be good enough to at least survive this change for where where the extension back is removed um and and have some uh Some uh interface that that supports both both cases where the extension back is there and it's not there and Yeah, so take a look of what's there right now if you're in to go and um Yeah, that's it awesome. So I think the the Interesting thing is how harrell implemented the v zero one specification Mark is looking for for it. One thing that I would like to talk to you guys is What's the approach for different languages in terms of? Extensions or well, and I don't mean the spec extensions, but extensions to To the sdk. Um, for example, things like validation, uh, like extra validation or Things like I don't know authentication for different protocols Should this be in scope of the sdk? Should it not what should be that like extend? What about like You know project specific extensions or like vendor specific extensions should they live in the sdk or not? What's the what's the view on on that from from you guys? a good question, um In our research, we've got some ideas for that And definitely a good conversation topic that We could probably jump into right after we share We share uh progress Mark, were you going to finish a thought? Yeah, yeah, so I I brought up the the read me from that repository And you can see that there's a creating a minimal cloud event in version zero dot one. Yep, or you can look at How how I implemented, you know, here's how you could define a visa or one event and obviously As we version the cloud event spec we would have to continually modify that So the the the question there is you know, is this the In the previous call we've talked about Meeting to support version interfaces or different versions of the cloud event spec Is this the what everyone was attending or to look like? as we Go to implement this on both go and other languages sort of On our end, it's we we kind of interpret it this way. We've got a maybe a few other ideas too Um, still we don't have a definitive answer just yet, but a lot of ideas for this So, uh, I had I have a thought around that so, uh, given that, uh, you know, you you Some somewhere when you produce the event first time you'll have to pick a version of the event that you want to produce so So the event producer will have to decide which version of the event The the producer wants to use But then the consumer could do a lot of things without knowing the The actual version given that a lot of handlers will be there for for him to to like a lot of functions that can operate Um on different versions of events are available for him in the sdk itself So Although I've created this package from v zero one for the versions zero one I would rather have it without versions code package and have Like, you know, like think I was thinking about like how hdp was into implemented and go like you have hdp package and the the hdp to version Support was added to this package without changing the the you know, there was no version package for it and there was The apa changes were minimal or even no changes were made to the to the Interface The basic interface there are some extra interfaces that you can take advantage of if you need to but the basic interfaces is the same Um, I I hope to have something In the same direction at the moment. It's not what I did I was more trying to implement what people did Basically, you know, here is the v zero one spec implemented as it is exactly With all the with all the details So I packaged it in in a package of v zero one But maybe we can change the direction and have something that is not Packaged scoped but still is able to Deal with different versions under the hood yep Agree with a lot of that that sentiment Have a few ideas on this but Gonna wait until it's it's our turn to share Um Well, Simon, let's let's hear uh on red hats end. Have you guys I know you guys have been working on a job implementation Uh, how's that going and do you have you learned anything and do you have any major? Uh problem areas that you need clarity on Yes, so so um, so brainwine. I've not been the main person working on it We've got a couple of different backend implementations of of the same api basically one One that's backed by a map of all of the To hold all of the attributes within the within the events and one that's backed with sort of a fit one field per Per attribute We were playing around with the map because we thought it might be more extensible and and particularly around sort of versioning might help for Sort of for versions past v zero one To for the sort of for a client client library to do something smart in terms of generating right versions for For a sort of a client application to use The I don't think so I think that probably internally a map is the right way to go Because of that that benefit to to extensibility for for future versions The other things that we've been playing around with is that we've we've got sort of the Sort of a quick and dirty implementation of a kind of gateway that Will root events based on the event type to different Kafka cues Use it uses cdi to fire events off that are then consumed by different cues and then They can downstream be be handled in different different ways Um, and I I think It's sort of based on what I've heard from from Matias. He hasn't had any significant problems with the current spec He hasn't particularly say dealt with versioning apart from being able to Sort of how to make it potentially extensible and uh to future versions. Um, and and I guess that the One of the things that the carol sort of touched on a little bit was sort of adding things in future in future versions I can see how that's straightforward to deal with but Taking things away Would be more difficult to To deal with sort of backwards compatibility And I don't know that Matias has thought about that a lot Yeah Okay And the I remember in our first call that your java implementation was public already Yeah, are you still working on it in that in that public repo? We are I can uh, hold on. We've got two different repos. I'll Uh, hang the links on the chat. Uh, give me a second I think we might have it in here already. Is it is yours project stream? Streams II that's the one so we have j cloud events, which was a kind of like a an internal implementation uh, that's what the uh That's what the kind of the event gateways, uh built on then we have an i o dot cloud events repo that uh Is more of a sort of a Sort of a generic api with nothing else there apart from I think there's a builder interface to to build Cloud events from from a java application Cool Okay, thanks for sharing Um, I'll jump in and share some of our progress. We haven't made give it me too much I have an example application in which I'm using cloud events It's a it's a purely reactive event driven serverless application reference architecture Which uses cloud events throughout for absolutely everything and I built a simple sdk just to serve that application's needs but by no means is it Um Is it something that should be published for the broader community to use because it's focused on a specific application largely But from there, I did a I did a few learnings and with chatting um with the rest of our team And especially brian who's our principal architect who's who's also on the line We have a few ideas for this and Especially one one big learning Um, so i'm going to share my screen real quick and just show off Uh, what we're thinking currently on this sdk and let me know when you can see something Yep, we got it Cool This is like a basic user experience that we're targeting for the javascript cloud of it at the cloud events sdk implementation Um, it's something that should be ideally as simple as this you can require in the sdk You can instantiate an event really easily. Maybe you passed in the version right here Um, and that event is already filled with same defaults Ideally and there are simple kind of getters and setter methods To actually manipulate the event and then lastly there's this publish method to go Send the event or do something with the event And this kind of simple experience. Uh, I think would really resonate with um, a lot of our users A lot of our javascript users with the serverless framework. It's very alike The super popular application framework called express that's written in javascript They do the same have a kind of a similar pattern, but for a requested response objects So anyway, this is kind of the the customer experience that we're targeting This doesn't really solve that versioning issue like in this example, this would be I guess this would be like a separate Type of class with unique getters and setters based on this version and some of these again may not be there If If that version changes and the specification changes in those setters or getters aren't are no longer needed Where would you possibly be returning a different type? Based on the version Returning a different event type A different a different object Based on which version it is Yeah, that's what I was saying it likely in this pattern that would be the case I don't think this is an answer to that because you know, these things would be would be different And on that note, I might actually brian. Do you did you have any thoughts around that versioning problem specifically? Yeah, man, I'm thinking that at least along the way Along the lines of how other people on this call have approached it to me. It seems that To me at least that version particularly is at the the code level in terms of like where you're just The version that you're of the the package that you're bringing to begin with Um, I mean at least I think it's the publisher I can't imagine that a publisher is going to need to publish Different versions of the event unless I'm missing something unless I Unless we we can see that there might be reasons why you would want to publish both A zero one version and a zero two version and etc. Well, actually that that's that's a good point I I feel like there would be reasons for that because if you're a publisher and you have all these subscribers You can't expect them all to upgrade their code when you upgrade the event, right? You'll probably have to maintain just like in an api scenario You have to maintain these legacy versions. Fortunately. This is just at the event level and not at the entire api level But as your event grid already has this problem because they're publishing zero about one on events Yeah So you have to worry about the backward compatibility for the lifetime of How long you want to support that service and is that I mean is is the approach for Maintain backwards compatibility there to effectively publish The same event just in in multiple different different version formats Yeah, I think So trying not to speak for clients Sure You know more than likely he has some way of mapping from their internal representation to the cloud event format In order to be able to then transmit it and so they'd have Potentially different ways of mapping that event depending on how we Move this back around But I think this also goes to the the conversation that we keep kind of dancing around which is how we're going to handle Either extensions or future properties that we add right because if we can Do it in such a way that it's always not just backwards compatible, but forwards compatible Then really of say a version 1.0 and a version 1.1 Even though 1.1 may have additional attributes they fall into like The same category as an extension so it still shows up on a 1.0 implementation of a receiver The only difference would be the cloud event version string is different and they may actually choose to be able to be They may actually be able to completely ignore that as long as we know how to handle Extensions and future properties in almost the same way Yeah Yeah, I agree. I think it's really dependent upon whether or not we decide to you know adhere to Sort of the the concept of semper there, right? I mean I guess the thing I'm curious about is is there ever a reason To effectively have to publish like an 0.1 and a 1.0 and a 2.0 Yeah, if you if you get into that scenario, then you need ways of potentially being able to bring in multiple different Yeah formats of that particular event, but I don't If as long as 1.1 is you know back was compatible with 1.0 Then I don't see a reason why you would ever need to publish both a 1.1 and a 1.0 Now that that said I do think um I think the code itself in terms of how you're interfacing with these kinds of things Uh would effectively remain the same, right? So You you could bring in you're just going to be bringing the same package of cloud events into Into all of your code and effectively if we do need to support different versions of the event Then that should be done at the kind of constructor level As Austin is suggesting here But what you would want is just that this thing knows it's going to be a 0.1 But the methods and how you how you write your code I would imagine would all remain Remain the same and it's up to the underlying event to be able to to deliver you that result in format at the end so I wouldn't want someone to have to like Generate an 0.1 Event and then run through a bunch of code to specifically do things for 0.1 And then do that same thing again with 1.0 and that same thing again with 2.0 Instead you should be able to generate your your event apply the properties and perhaps get you back Okay, here's 0.1 format of that. Here's the 1.0 format. Here's 2.0 format depending upon which one do you need to publish? Well, that would be ideal. Absolutely. Um, and I don't know if this is a solution This is actually the next thing I'm going to show is something that We came up with just because we felt it could solve a lot of problems um So I think what's what's going to set cloud events up for success is how well the community can integrate with it How well people can build kind of open source projects to extend cloud events How well vendors can build integrations into cloud events Um, so that it integrates with their their service And this goes back to the extensions Topic which we've discussed briefly and we need some clarity there But one thing we found and this is brian's idea, but we think the extensions experience The the big learning of this is that the extensions experience should be thought of Right in the initial versions of these stk. So if we were going to propose one change to our roadmap It's that we figure out the extension story because we think extensions In addition to just being custom properties within the cloud event envelope should actually Be an experience that is also incorporated into the stk And an extension is something that you could bring into the stk to add like a hook or a middleware into that stk So that within that hook you just bring in that little extension module In that extension module can manipulate the cloud event data Can do all all types of stuff with it So here's kind of a basic experience For example of this extension might be something as simple as this Where you just have like a function. There's an action argument The event object is passed through and then maybe there's a next function that you call So you'd read the action Uh, and maybe this is like what the end user is doing with the cloud events stk Maybe they just set some data and this extension, you know, you could say if the action is set Like that means they just set some data and I want to like look at the events To do maybe one of the following enforce an organizational policy Set a default for an app or a team or an organization Maybe do handle do some custom encoding for different content types Handling transports isn't really part of that that specific example Just build any type of open source helper utility library to manipulate the event but also add support for vendors So again, you you read the kind of the action what's going on in here Uh, and then you could modify the event or do anything you want with the event as a result of that And this is like a pretty simple concept. Again, it goes back to like express j That's middle air or like uh redux if you're familiar on the front end I've just given people ways to To modify the event do extend the sdk And then within those extensions in the sdk those extensions could also add properties to the cloud events themselves And hopefully the community would build some of these, you know our Our company would love to just build a event gateway extension for example And what that extension would look like is it would look like, you know, if there is a publish Function or method on the event up here Whenever we would just write an extension like this so we'd say whenever the action is published Send this out via the event gateway Publish it to the event gateway and that could route it to different functions as a service And of course before publishing it this extension could also add some data to the cloud events envelope For the event gateway to interpret later So, you know, we our company would write this thing And then our end users would simply when they require the sdk They'd use this, you know, something like an extend method pass in the extension Into it our event gateway extension And automatically whenever they instantiate a new event or something like that That extension would just be baked in All the extensions would be baked in so that the developers don't really have to think about a lot of things So other example for this is in my application in my reference architecture that I'm making I'm starting to put application specific information within the envelope Within the cloud events envelope. I want to put like the app title I want to put the stage of the application. I want to put maybe auth information for that application And I'd love to just make a application some type of app extension Where people can just set some custom properties here like the name, you know, auth info stuff like that And that app extension could always like prefix the event type with like the title of the application, you know, no matter what It could do a lot of stuff and add application specific properties to the cloud events envelope And it would be a very convenient experience. Again, you know, this that app extension could be an open source project People just bring it in and it would really bring kind of application features to to cloud events Again, they just pass it in like this You just add it in once and then every event you instantiate will have all that stuff baked in Is this a solution for enforcing organizational policies? We think so whenever you set data, you should write an extension Your your org can write an extension to check that data make sure it's formatted correctly Setting defaults for an app team or org absolutely Now custom encoding handling encoding issues perhaps perhaps extensions could do this like on the on the publish action for example Now handling kind of different transports, you know, yeah, I think on publishing absolutely And perhaps this extension solution is I don't know if this could be applied to solve the versioning problem too But Yeah, haven't really thought about it just just thinking out loud there But anyway Our biggest learning is like thinking about this experience should be one of the first things that we consider When designing the sdk because if we could create a great extension extensibility story for cloud events and we have that in the specification We need to carry that into the sdk That is going to be fuel for community growth for vendor support for for an ecosystem to grow around this thing So that's um, yeah, that's it on our end. We're targeting this user experience We learned that extensions are super important. We like to think about them in advance and it's bigger than just custom data Yeah, I like the idea in particular I think it implies then that there's some sort of Agreement or set of specifications around these extensions so that people Who write the extensions for each various language can adhere to that specification that way regardless of what language seems using They can get a similar experience assuming everybody tries their best to try to implement all those extension specs for each of the various languages we support so they get some level I don't know the inner abilities right where the consistency across the languages and stuff. I think that would be really really cool That's a good good point Doug. I mean, I guess there's a question in there if once you start going across language um, I agree that this consistency is nice from the perspective of the having level of familiarity uh, but there's also clearly just significant differences between languages that can make that uh relatively challenging And certainly I think the way that a javascript developer thinks about Doing these kinds of things versus the way that a java developer thinks about them They're often You know worlds apart to some degree And it'd be nice to effectively be able to take it at least to form things in the way that those communities are familiar with Oh, yeah, I definitely agree that the way that they'll be presented to the user may look radically different in some cases But if the same Features are available across languages. I think that's going to be the big benefit to the user Or develop. Yeah, absolutely. Yeah. Yeah, that's a hard thing to first maintain I mean just just ensuring that we get parity at a language level It's probably going to be up to the implementer of the extension to begin with to say Yes, we support these and you know, we're doing our best to to produce it in every language I just I would just say that this idea addresses a lot of my Concerns or questions that they had at the very beginning So, yeah, I definitely like the idea of having this Into this decay and having this and this also aligns with what I said, you know that It's not only that the event specification. It's more about what you can do with it and like the extensions will be the The way to do something with it so that different versions of events won't matter that match if you have the Common interface of saying what you want to do it with those cool okay I think that's it unless Unless Doug or or Brian or anyone else wants to share anything any other thoughts No, we don't we don't have code yet other than the code I wrote for the demo So nothing big this year yet Okay Yeah, I'm good on on my end Cool Sorry, Austin. Can I jump in again for a second? Um, so, uh, I'm gonna share my screen The other thing that that we did that I I completely forgot about was There's some there's some technology called the heptio event router, which is a It's a kubernetes something system top kubernetes and Emits events based on kind of what's happening inside kubernetes So we deployed that an open shift and the the events that come out of the heptio event router are a little bit odd to say the least but We we deployed a a watcher for those events and then Use the Use the line It's on the screen now is Is a sort of an example of how we use the the java SDK to to turn this for data event sort of the heptio events into Into cloud events and then we So this is a sort of a helper class and then we published those onto a kafka topic So we had a at least from a sort of a build perspective not a not a dissimilar sort of developer experience from Sort of from your your javascript Sort of api developer experience Yeah, I can see it here. It looks it looks really good um I say that the the kind of the content of their events is a little bit a little bit funky but They only have two event types and so we we try to split out their event types into things that make a bit more Bit more sense for a a sort of a consumer of those events that might be interesting different different topics But we found that sort of the Generally what we built in a java SDK kind of made sense And then those could be consumed downstream by different subscribers to the kafka topics Yep, cool stuff Okay, moving along here our second agenda item was to identify areas where we need clarity And further alignment. It sounds like we have two big ones and let me know if i'm missing any here But just extensions like trying to figure out how the extension story carries into the SDK And also where those extension properties are going to end up at the end of the day And then versioning how do we build this in a way that's future proof? Anything else that we're clear Problem areas that we need to we need to figure out right now at this stage I I have a question related to the the bindings so um I guess it's it's it's just the nature of of how the the standard looks like right now, but We have we have spec, which is 01 version 0.1. We have htp binding, which is version 0.1 They seem to be version independently But are they or will this is probably more a question to dog maybe and mark are they version independently or they will always be a version together Or what's the idea because i'm asking because you know the the bindings for example The htp binding specifies how the extensions are carried But I imagine that if extensions Are not in the the bag but our top level that the binding must change as well. So they're kind of They depend on each other. So i'm curious what the story there So I guess I kind of always assume that while there's different specifications and they may have slightly different life cycles in terms of like the core spec could be released maybe You know once every six months the htp spec could be released more often Right, so there may be some difference there, but I always kind of assume that They always are within the scope of say version one Right and and they're sort of from that perspective always group together And that if we ever wanted to radically change the htp spec It would almost have to be a completely new htp spec that's completely different from the current htp spec Got it. That's a very fair that's it's a rarely major split That's a fair point dog But I mean I think the question is kind of interesting because it leads us down a path of where You know the you may have a specific version in the event that still adheres to You know o dot one o dot two etc Whereas the binding in terms of how it's delivered has entirely changed How do we reconcile that with kind of the versions in the sdk? Which You know, are we going to need to be able to bring in? You know a binding version separately from the the event Uh, you know the code responsible for generating the event itself And that seems like that's getting pretty complicated at that point Yeah, I don't know that this maybe I honestly I think we just need to think more about this because I I mean if we change the htp binding so radically like for example, let's say we get rid of a The extensions bag right and they all all extensions now become top level things for the jason coding or htp That's a radical change any of the core spec didn't change People are going to think this isn't a one point though anymore. This is a 2.0 And maybe we need to think that You know, maybe a binding or transport change does bump up the core spec version. I I don't know we have to think about this because it's I love for them to be independent, but maybe they really can't be I just don't know Yeah, I mean it has implications on on The consumer side as well because you know suddenly if you were to if you were to get 1.0 events or as you're describing that you have 2.0 events that looked exactly like 1.0 defense So let's let's say the binding change was that instead of using c e as a prefix on headers You know, we used you know, the whole cloud events word as as prefix So this changes radically the way that we We think about the binding, but the Event ends up looking the exact same at the end of the day. Yep in that particular case A version change to the event actually could be relatively annoying to the consumer side Whereas you know really the only thing that really needs to know about that change is the sdk Yeah, I don't know. Hi. Does anybody have any experience on how other people deal with this other specs that deal with the You know schema versus transport specifications So the way I see that is is kind of the problem with the transport right now is that in structured mode In structured mode, you have the envelope which is It does not depend on the actual, you know actual structure of the Of the of the of the event. So the so the spec it doesn't depend on the spec itself Because it grabs the entirety of the spec and packages in this in this in the body of the Like I'm talking about the htp htp bindings, but it packages the entire Body of the event and and it's it doesn't depend on the structure Whereas in the binary mode because we have to inspect the structure Of the event where the context Is is treated differently Like extensions are treated differently then yet It causes this problem, right? If it wasn't the case there were no problem if the envelope that the basically transport envelope if it Grabs everything then, you know, it it it kind of is independent of the the thing it carries um I'm thinking even if we remove the extension bag in the binary mode and you have, you know, the top level attributes for the extensions what happens if Like I understand that extensions at the moment they support values like keys are strings, but values can be objects how those objects are encapsulated into Into the headers This is another It's another surface where the where the spec leaks for the transport binding, right? It causes this leak that that Transport transport has to handle and because of that it depends on the spec So I don't know if if we will be ever able to address it fully um If we support the binary mode like if the binary mode like binary mode is kind of tied to the spec version Whereas the structured mode seems to be uh independent of the spec version. At least that's what I see at the moment I don't think about that much or if I agree or disagree It's a complicated question. Yeah, of course it goes way beyond the SDK um As the case cope. So I guess it's uh, yeah But that but it is a good topic and I'm going to add to the agenda for tomorrow's call Not necessarily because I don't think we come through resolution on tomorrow's call But I think people need to start thinking about this and come back with ideas I'll call it one other uh kind of interesting angle here. So let's assume that um again, not everybody's going to keep up with the the latest versions of uh, the specification And I want to effectively be able to write code that could potentially publish to You know something that adheres to the one other stratification and something that adheres in terms of transport binding It's something that adheres to the you know o dot one without having to change out my code How Does the SDK know which version it's needing to publish based upon The system that it's communicating with or how does it know how it needs to talk to it? Could that be covered in an extension? well, I guess the point is this If you're wanting to to be agnostic about it, right? um You're you almost lose that ability or you need some method to effectively be able to know Okay, this endpoint. I'm trying to reach which version of cloud events do you speak? Yeah, are you speaking do you speak o dot one or do you speak one auto? because then I never thought that there'd be protocol negotiation for version I think so either. Right. Just yeah I just consider the events being asynchronously sent out and decoupled from any uh transport level Communication getting it from one place to another Well, but so take the SDKs, you know case uh if If I wanted to be able to write code agnostic that worked with, you know the event gateway and works with azure event hub For instance, and one of them is still on o dot one than the other ones on 1.0 Uh, do I effectively, you know need to write Choose our lines of code and switch based upon where I'm trying to send it to or is there a method that it can figure out You know, hey, uh, I know I need to send a you know this over the 1.0 Transport specification here and here I need to send it over that one So I think this is an interesting problem in the sense that I think it seems to me that once once we have a version I guess we don't have a version 1.0 but It seems to me that once we have a version of 1.0 version of of cloud events then consumers who Commit to support those 1.0 1.0 version will have to support it But practically forever in the sense that transport might change and maybe that it might be a Negotiation in the transport layer and probably there will be a transport negotiation because then we are talking about Two entities that can negotiate or in terms of hdb binding. We have this Transport negotiation very whether it's 1.0 1.1 or 2.0 but in the context of even version I think it's just impossible to Negotiate that because of the asynchronous nature of events So it seems to me that version 1.0 of events spec will have to be supported for I don't see how it would not be like Well, well, again, that's assuming that you're directly talking between the publisher and the consumer and more than likely these events are going on to You know some event bus Being enqueued into some system for for delivery asynchronously and so you won't be able to get that level of translation Yeah, anything it's going to be up to kind of A middleware That's delivering it between the consumer between the producer and consumer It will say oh, I know that all of my consumers are at this back. I'm getting this You know, potentially a 1.0 event coming in but my Consumers are 0.1 Maybe I need to down rev the event And be able to do a translation of that in middleware Exactly. So there is a middleware, right? So there is a middleware which is Affected by the transport binding. So the middleware has to know can negotiate the transport Binding or whatever the transport version is used, right? It can negotiate with the with the producer with the consumer can negotiate that What they cannot negotiate is the event version or the What what is being carried and this will like the middleware will be responsible of Ensuring that whatever it delivers to Will be able to uh, it will be able to deliver it. So in certain cases it would have to convert the event between versions, right? Like the middleware's responsibility would be to convert those versions in case It's the consumer of this middleware doesn't know how to support certain version of the event Yeah, and that makes certainly makes sense to me. I mean, I think it's between the the sdk and the middleware Uh, the really only the the only version that they really need to be aware of there Is just how they're speaking to each other. So how they're you know, the transport binding itself But you're right. Yeah, then the middleware needs to take over from that point and understand the consumers and understand Which version of the event they're expecting Yeah But maybe i'm not following properly, but I would have thought that sort of each hop along the way here It's almost like a completely independent Uh transport of a cloud event, right? So from the event producer to whatever piece of middleware That that event's producer is going to have to choose some version of ce and then some Transport related to the cloud event and send it across and then that middleware Is going to have to accept it in that format and then it may do some translation You know, it might even translate to cloud event version 2o You know and with with the completed binding and that's it's just to melmind. It's just another hop along the way But each hop does its own translation and needs to figure out how it's going to send it and I kind of view how it decides how it's going to send it Is almost out of scope for us even in the sdk world The sdk just needs to provide the mechanism for someone to specify What version of cloud event what version of the htb binding? But it's not necessarily our responsibility to figure out how that information gets given to us from the event receiver Yeah, I agree with that. I agree that's I guess the discussion came from the fact that we needed to clarify that On that note, I'm just going to move along here because we're running out of time Um, it seems like we've identified a few areas. Uh versioning is is an issue There's a couple versioning areas. We need to figure out cloud event spec and sdk Mismatch, I'm not sure if we found any solutions for that just yet And the spec cloud event spec and the transport binding spec Might be might be some issues there as well. I'm not sure As well as the extensions stuff. So Um With respects to extensions, I just wanted maybe we can get to some resolution here Do we feel that thinking about extensions in advance in this initial version is a good idea? I don't I don't think there is a way not to think about them. I I currently I'm kind of blocked by Not Not knowing how to address that. So I think it's uh, something that we should address Yeah, I agree. This this to me is like security Um, you need to kind of think about it up front to make sure you can plug in the right stuff later on Even if you don't necessarily define it all right right up front. You have the right you have to have the right hooks in place Okay All right, it sounds like we have a bit of a scope change there for this zero dot one milestone so something for everyone who's Who's implementing this to think about uh, how to how to support that extension experience uh upfront Um, so I'm going to add that into the cloud events sdk version zero dot one And at the same time, I I think we're at a at a good point where centralizing these efforts in the cloud events org Would be helpful So we have like one place to look for all these things and we'll make it very clear These things are not production ready. These things are currently works in progress But I do think having them in one place so that everyone can kind of observe our progress and look at the various implementations would be helpful Um, Doug, do you have any suggestions as to how we can go about doing that? Yeah, so as you and I were talking earlier, I think um, if we create a single repo for everybody to put their work into I think that might be a good starting place that way people have a single place to go look for it And that's irrespective of what language they're going to be implementing it or using Um, I know that some people may want to have a separate repo per project If we have everything under the same repo while it may cause some noise in terms of issues Po requests and emails and stuff. I think being in the same repo helps ensure Or at least encourages the possibility of us all staying aligned As best we can. Um, that way we don't get some project going off in a completely different direction At some point we may choose to split it out because things maybe get too busy But I think initially we could start out with a single repo to put these things. I think that might be a good place to start Yeah, especially in the design phase because I think centralizing the conversation Yep around the design in like a kind of single repo issues area would be would be helpful, too Yeah, I can I can I parse what you just said, Doug? Yeah, sorry did you say a single repo for all of these or As a starting point. Yes a single repo under the cloud events org And we have multiple languages in it. Yes I see a problem with that on purpose I see a problem with that later like would go because the the way that go works and how the things are packaged That we will don't know everything including other languages But I think I think at the beginning when when we start the value that austin and doc said I think the value is there And so I'm I'm okay with that I mean we could have one repository for storing like You know a set of readings and descriptions and those kinds of things and then if we need to separate out the code and to separate Rebo so I think that would be Yeah, I was going to say something similar Brian. I think if we get to the point But not yet when we get to the point where we have a common document that describes How extensions should work at a functional level and then you know how we just how The different set of extensions that we define should work across all languages So that I think that does make it more possible for us to then yes Split it out to some repos because then people are saying okay this repo over here Adheres to those specifications to find in the common repo, but since we don't have that quite yet I'm not sure we could do that quite at this point in time Yeah, it sounds okay Great, we made a decision there. It sounds like dug if you can Set this stuff up so that we can start pushing things to it That would be helpful. Maybe we could be in a good place to do that Tomorrow yeah, good question for you. Do you want the repo to be called SDK or SDKs? And that's where the meeting goes for another hour Okay, I'll flip a coin It's up to you Doug use your use your excellent judgment We're screwed right there, okay All right. Yeah, so let's let's just present our progress We'll give an update tomorrow during the during the work group call and you know Maybe Doug will have some have instructions for us He could share them on the call and then we'll start pushing things and everybody in the work group could fall along a bit more easily So in the meantime, yeah, let's think about extensions Let's think about this versioning these versioning issues and also discuss them within the broader working group Sounds good. Yep. Thanks Austin. Thanks all Thank you all Good work. Take care. Thanks a lot