 All right, it's already eight o'clock. If other people join, fantastic. Either way, let's go ahead and dig into this. Sure. The reason why we... Where are we keeping notes? Oh, there is a cloud events SDK design proposal, Google Doc, which I'm gonna paste into the chat room right here. I didn't know if you were gonna use the normal one. Yeah, I'm not sure if I have, I guess I could add a whole bunch of suggestions on to it, but I think this is fine for now. Okay, cool. And we were just joined by Carol. Hi, Carol. Hi, everyone. It's Carl here. Carl, great to meet you. We're just kicking it off right now. And I just pasted the Google Doc where we're putting notes, ideas, everything into. Yeah, yeah, I see it's being abated life right now. Yep, that's right. Cool. So to start from the beginning, the reason why we're doing this is because we came out with this great specification for coming up with a common envelope for event data. And it's gotten a lot of attention already, but we need to make it easier for people to use and a natural next step is usually to create some SDKs. When polling the serverless working group and the cloud events group, it seemed like a whole bunch of people were already making SDKs. They were just going off and kind of doing it in isolation. So we thought, hey, let's bring everyone together and see if we could kind of, you know, outline some priorities and some design goals for this thing. And maybe we can collaborate on these things together. So that's the premise for all this, the why. I think we should go ahead and do a quick round of intros. So, anyone want to go first? Sure, this is Mark Geek, I'm with VMware. I've been involved in the serverless working group since it started and cloud events. And I am the lead head honcho of dispatch, which is an open source serverless framework that sits above other fases. Great. Maybe I'll jump in real quick. My name is Austin Collins. I'm the author of a piece of software called the serverless framework, pretty popular open source project and also the CEO and founder of a company called serverless Inc. Been involved for the serverless working group for a long time as well. And, you know, our company works on vendor agnostic abstractions to help people build serverless applications across any serverless infrastructure provider. We care a lot about standardizing some of the popular concepts within serverless architectures because we believe a lot in vendor choice. We want to make it easier for all developers to use serverless infrastructure across providers without having to kind of get familiar with all the platform quirks, become respective platform experts. They should just have this common experience for deploying, you know, serverless functions or using other serverless infrastructure across providers. And that's one of our big goals. That's why we are big fans of cloud events and some of the other things that we're just starting to talk about now in the serverless working group, like coming up with standard function signatures and whatnot. Yeah, and that's me. All right, I could go next. So I'm Carl, I'm also with VMware and I also work on project dispatch like Mark. I was involved in the event's work for dispatch and I actually implemented the first version of cloud events in dispatch. What I'm looking forward to is SDK helping with, first of all, tracking the spec of course to be able to, you know, version the SDK with the spec. So I don't have to follow the changes. Well, I will have to follow the changes anyway, but to be able to pick up the proper version SDK and yes, make it easier, make my life easier as a developer, consuming, producing and dealing with cloud events but I'm really happy that this thing came alive. Me too. I can go next. My name is Mathias Wessendorf, I'm with Red Hat. Today I have two co-workers here because we are at a face-to-face meeting. We started looking at cloud events from messaging perspective. One of the motivations was so that in the Java Enterprise ecosystem, there's the Micro Profile Initiative and they're going to start a new messaging specification that's not JMS. And one of the idea goes, there was as well that for eventing, it could be modeled after the concept of cloud events. Yeah, when we were digging into this, we were starting to play with some API and stuff like that. So that's why we are very happy that we can participate here and I added some proposal already to this document that we currently all staring at. Yeah, I saw that, great work. Thank you. Was that everyone? Probably not, I joined late. Klaus here. Hey Klaus. My name is Klaus Dysen, I work for SAP. We are contributing to Q-plus and I'm currently starting to play around with cloud events for Q-plus and of course I am. Yeah, I suppose everybody playing with cloud events right now is starting with the same thing. So somehow working with those attributes we defined so far and so on. And maybe that's quite repetitive. So, yeah, I would be happy to see that if some common libraries somehow evolve. Great. Howdy, this is Scott from, Scott Nichols from Google. I'm still ramping up, so I'm here to listen. Great to have you Scott. What team are you on? What product are you focused on over at Google? Sister team to App Engine. Yeah, cool, thanks for joining. Is that everyone? Mike Roberts, did you go already? Hey Austin, no I didn't. Yeah, hi everybody. I haven't been on any of these calls before but I've been following the group for a while. And I bumped into a couple of the folks from Google two weeks ago when I was over in Velocity. So I thought I'd finally join in and just lurk on the sidelines. All right, great to have you. I think that's everybody. Let's go ahead and jump into the agenda here. And I'm wondering if anyone has feedback on this agenda. Here's kind of how I thought this could work. We list out the use cases for the SDK. There's already a pretty healthy list going on the Google doc. And then we go through and we kind of stack rank those. We figure out what's the most important, what are the most important things that this SDK needs to do to actually put the cloud event specification into developers hands tomorrow. And so we go through, go through the exercise of stack ranking these use cases, see where our priorities are. And from there, we can start breaking this down into some potential milestones and the scope of each milestone within respective cloud events, SDK versions. And so on the Google doc below the potential use cases that put it in a milestones scope section with different cloud events, SDK versions. And we could just put bullet points under each in terms of that describe what we think that version should seek to accomplish. From there, it's gonna be up to us to figure out how the work actually gets done. I think there's no requirement that all of us here in the room go out and do this work, but we do have to figure out who might be focusing on what. So yeah, I figure we take it from there. The outcome of this should be getting some milestones and scope down for the SDK versions. And then we'd like to go take that to the main service working group call this Thursday and just present them with kind of what we're considering and get some feedback from them. And from there, I think we might be able to get a few more ball of the tears to help actually implement all this. Anyway, does anyone have any thoughts on that agenda? Does that sound okay? Or do you have any other ideas? Sounds good to me. Okay. Well, let's kick it off then. There's a list of potential use cases. These are all numbered, but they are not yet prioritized. That's our next challenge. So first off, before we go in and prioritize all this, does anyone have anything that they feel should be added? I'm just pausing because it's likely a few of you are reading this for the first time. And I can go through a couple of these. I added in a few of them, so maybe I'll provide some context onto each one. The first one here is instantiating Cloud Events easily in code. This is simply being able to require in the SDK and do some type of, it could look like class-based instantiation where you're just creating a new instance of the Cloud Events class. You're actually kind of crafting this Cloud Events and setting the values of the event itself. This seems kind of table stakes if you want to actually do anything with an event. You have to build it first. So that's what that is. Instantiating Cloud Events easily via event schemas. Not entirely sure how this would be implemented, but perhaps it could look something like JSON schema, which you're able to pass in a JSON schema and create instances of that due validation against the schema and the rules that are baked into that schema. Bringing an event schemas, I think could help out a lot to solve problems around testing events, solve problems around validations, transformations, and even generating mock events to help test out your serverless and veteran architectures. Number three, assembling Cloud Events from various transports. So there are different transport specifications that are being included as siblings to the Cloud Events specification. This is how you handle Cloud Events and HTTP, for example. Ideally, if this SDK is going to make developer lives easier, it should be able to create Cloud Events from various transports. We got to figure out how that could work. So a quick question there. When you're talking about transports, but what about the encodings? I think encoding should absolutely be included in this. Maybe I'll add a quick update. How about assembling Cloud Events from various transports and encodings? Which are slightly different things. Yes. Additionally, validating Cloud Events by including a schema. I already discussed that briefly. Transforming existing events into Cloud Events via transformation mappings. This one's kind of an interesting one because it's the early days for the specification. It's very young. And we want to make this something that people can start using right away regardless of industry adoption. We've been fortunate enough to have some of the industry influencers involved in the Cloud Events conversations. And a lot of them are implementing this already, which is amazing. But we want to move faster and we want to kind of make sure Cloud Events fit nicely into all the things that people are using already. So being able to simply transform popular common events on different platforms, whether it's AWS, whether it's Google, whether it's popular webhooks from Stripe or GitHub or something like that. Being able to transfer those things into Cloud Events, I think would help make this, I think would greatly help adoption here, especially if Cloud Events has some great experience around being able to do those transformations almost automatically. So there's, that's what that's describing. Do you see though that as a, strictly as an SDK issue or is that like a separate repo perhaps containerized drivers that would then be able to transform those events? How would you see that working with the lens of this SDK effort? Yeah, great question. I'm not entirely sure yet. If I'm just throwing ideas out there, could we investigate some type of language agnostic way of defining these transformations that the SDKs could require it? So when they receive some events in its kind of native format, and you're expecting that and you could add in this module that already has the transformation mapping into the SDK and it should be able to use that, that knowledge to do the transformation automatically. Yeah, because a lot of the times the way I think about it, you're having to pull or wait for an event to come in from some of these foreign sources, which is a little bit more than just transforming the actual Cloud Event. And so by itself, having the transformation is useful but not sufficient to be able to actually get the event in and be able to sit on that then. Yeah, there's a few phases to solve that problem. Getting the event into your runtime, where the SDK is, is kind of what I've been focused on specifically. If the SDK can help beyond that, I'm not sure how it would, but open to investigating it. But talking, having this conversation, these are other adjacent conversations that are happening within the working group around event sources and whatnot. I think all those things need to be factored into this, but right now, I believe the SDK is only gonna be able to handle kind of what gets into that, what gets into the runtime. Did someone else have a comment on that? Yeah, I was gonna ask, and then this may be because I'm a newbie and I didn't realize this was a smaller group than the main group, but yeah, I guess for this whole area, there's even a high level, is this sort of solved on a component slash architecture basis or is this on a language basis? So just purely thinking about it in terms of AWS, like is the vague idea at the moment to deploy a component that does the translation or is it more around having, doing it programmatically within each Lambda function? I think that this is more a concern of maybe something else similar to the event gateway idea so that understands there are certain incomes from HTTP, Kafka, MQP or whatever, and then you can use a component that does the filtering or transformation and then it would convert it into the proper format and then your SDK is just be your SDK that you work with the object with. I think the transformation is likely more a component sitting next to it like in order to trigger the process and to get like the full payload out. I'm not sure if it's directly concerned for the SDK itself. I would see it more as a separate thing for applying filters or transformations in order to extract something from MQP or whatever into a cloud event object with the proper metadata. Okay, it's super interesting to me. Yeah, I think that there's a few ways we're probably gonna have to go after this problem in general but here's a simple use case that I think you'll be familiar with, Mike. That is AWS Lambda receives an AWS S3 object-created event and that's in Amazon's native format. Being able to just take that native event which is already in JSON or being able to take that pass into the cloud events SDK and out of that, we're just using one method on the cloud events SDK, you get the cloud event flavor of that, the cloud event AWS S3 object-created event. Yeah, that sounds, to me, sounds brilliant because that gives you the whole cross-platform nature then and then you just take 98% of your code and put it in Microsoft and you're good to go. Exactly. Now for other event sources and other places where events are coming in, there's probably gonna be some more complications involved. Yeah, I was about to say because the example here is actually really good because it kind of draws a picture. System that can generate the event and send it versus, for example, a system that generates events but isn't able to send it by itself and you need to do some polling and then some sort of a component enters a picture that will poll for those events and generate actual cloud events and this component is then able to send them further which is like a different use case but I think in this case, it's not the role of SDK but the component will use SDK to produce those cloud events but it's additional work to actually get those events in some custom format and then convert them to cloud events. Yep, that's right. Okay, just gonna move through the rest of these real quick. Receiving cloud events, easily encode, compliment the first bullet, Iran has mentioned defining an API to access the properties of a cloud event. I think Doug Davis added this one in and I believe what he was talking about is something similar to just having the cloud events kind of be an instance of some type of class that has getters and setters for accessing the data. I believe that's what I saw in Iran's early examples of this like six months ago but it's been a while so I'm a little fuzzy on this. Next step was generating mock events from a cloud event schema. Chat about that briefly already. Cloud events extension SDK add-ons and modules. Now this one is pretty interesting. In the cloud event specification, there's this extensions concept where you could just put in a lot of different custom properties essentially and the reason why this extensions concept was created was because we don't know what should be in the cloud event schema today. It's too early. We need to get this in the hands of users and we wanted to create this area where users and vendors could come up with their own properties within the cloud event envelope to help facilitate anything to do with event dispatching and processing. So that's what- Sorry, I was trying to interrupt. I just have a question because I'm curious, do you guys see this extensions thing being used for things like for example tracing or it's a wrong place to put things like that? Like a tracing ID or something like that. I'm curious if you've seen this being used this way or do you see it as the proper place for something like that or? Absolutely, yes. Tracing is something where in this world where events are increasingly being transported across environments, being able to trace where this event has been is gonna be very, very useful. This might be something that we put as a first class citizen within the cloud event schema in the near future, but in the meantime, this extensions area gives us a sandbox to test out some of those ideas. So tracing is something that a lot of people in the working group are very interested in and I think it's probably gonna end up as an extension for a little while until we get some real user and kind of market feedback in terms of like what people prefer. Now, the interesting part with respects to the SDK is because the specification has this place where you could put in kind of any type of data that you want, this creates an opportunity for the SDK to almost have like an add-on or kind of modular experience for working with that extra data that's set as an extension. So for example, if you're a company that is providing some type of event tracing service, you can have your own, you could have some, you could work off whatever the tracing extension is that people are using or come up with your own and design a module with the SDK to help you do some more processing on that event or to help people, I don't know, maybe just pull in tracing information off that event really easily and port it right into your system or your dashboard or something like that. So this is just, this is a very early stage idea. We really got to flesh it out, but I think that there's a lot of opportunity here for the SDK as well as for vendors and end users to be able to extend the specification and do that through the SDK via some type of add-on and kind of module experience. Does anyone have any questions on that? Okay, moving on to the next one, transforming lower level events to higher order events automatically. There's been a few people in the working group who have requested this idea of getting away from like provider platform specific events and trying to come up with some higher order events for things that the providers, for events that the providers and platforms have in common. For example, in the big demo that we did at KubeCon, we had everyone create, I think it was 11 different serverless functions to process two different types of events. So these functions had to be written to process two types of events. And those events were an AWS S3 object created events and then a Microsoft blob storage object created events. And because the functions had to write logic to handle both these events, yet the events kind of had the same properties, the same ideas in them, what emerged from that was just requests for, hey, can we just create some general storage object created events? That's not platform specific, but maybe an SDK or something could take in a Microsoft blob storage event or an AWS S3 object created events and output this kind of general storage object created events, which has goals around, just being easier to write code around without having to worry about, what specific platforms are including in their event data and also might get us a bit closer to portability one day. So don't know how the SDK would be involved in that but throwing it out on here. Yeah, that's actually very interesting to me. It sounds, I mean, if this work, they'll be great, I would say, because I'm being able to generalize events like that. I'm just curious how, maybe I'm going too far for now, but I'm really curious how that will work because each platform has some like its own ways of accessing the actual object that was created and doing something with it and probably some specific identifiers and so on. So I'm curious, what will be the use case of the general, like you probably wouldn't be able to access the object without a specific platform SDK. So I'm curious, what's the use case of having a generalized event like that? How it would work is something that, we'd have to figure out if it's possible and what that implementation would look like. Going back to the S3 example, I believe you could take Cloud Events SDK and if it had that transformations concept in it, you could just build in a transformation that takes AWS S3 object created and converts it to a storage object created event. As long as you kind of receive that event already and you're able to process it in code, same goes for the Microsoft version as well. But it's early days, just throwing the suggestion out there, but there's definitely a lot of interest in this, especially just to help people write more portable functions to react to anything. You could see how storage object created, that pattern could be applied for database record created or something like that. And these things cover a broad surface area, but anyway, the idea is out there. We could dig into it to figure out how to work and if it could work. In a lot of ways, this and five should be combined, because this is really a subtopic of the general transformation. Great, I will put that as a sub bullet point here. I was literally just about to ask how this is different to five. Well, it is different, but it's very similar because instead of taking the native event and transforming it straight into a cloud event, it's actually transforming it into a totally new cloud event type. Yep, that's correct. Okay, almost through these, configuration extension for adding middleware the SDK can use to publish events. Yes, that's right, there's a few people who are offering middleware for cloud events, infrastructure to help with the general dispatching and routing of events to wherever they need to go. Our company does that, we have a product called the Event Gateway, Microsoft, who's represented by Clemens in the serverless working group. They have the event grid, we have dispatch, a lot of the serverless open source compute platforms are doing the same thing, and it would be neat if there was a way to just include the middleware or whatever you're using to help facilitate event delivery into the cloud events SDK, so that what the developer gets, what the experience that they get is simply being able to do cloud event dot publish, they call the publish method or something like that, and because the configuration is already stored within the SDK, that cloud event will immediately be sent to wherever it needs to go. This could be kind of native configuration or it could be implemented as an extension if we add in that functionality for extension add-ons or modules. Is this where something like Microsoft's bindings feature might kick in, because that's one of the things I'm really interested about seeing from this kind of open standard. Highly likely, yeah, that could be included in here, I'm sure it could be baked into the SDK in a number of ways actually. Myself and John Chapin, we've always thought that that bindings feature that Azure Functions have is one of its clear differentiators over Lambda. Yeah, we've heard the same. A lot of people really appreciate that feature, and there's definitely a lot of opportunity to leverage that and even replicate it perhaps in this SDK, but I think we're a little ways out from that. Last up, version SDK with specification. That's simply, as the specification gets changes, we're gonna come out with a new version of the SDK. Pretty simple, pretty simple use case. Okay, that's everything. First off, are we missing anything? Does anyone have any further ideas in that we've been through all those? I think there's also more meta logistical issues with respect to, do we want to think about how we would formulate these SDKs into GitHub, naming structures, how we would extend that, language, how we would, what would we want? Generic names, do we want language specific bindings to make it flow better within a language? I think that there's a whole bunch of meta issues beyond just these. I totally agree, and we'll have to figure all of that out. I think perhaps the first step will be to figure out what this thing does, what it's focused on, and then figure out how we're going to coordinate logistics, figure out the implementation details, figure out where this thing is gonna be hosted at the end of the day, which I imagine is just gonna be the cloud events at GitHub repo. All right, do we want to go through the exercise of trying to stack rank these? Does anyone have any strong feelings as to what should be number one? What should be the first priority? I would say basically creating cloud events with the proper version of the SPAC and creating the objects like the must have for the SDK, because that's where you start. But I would start with this. Can two and four be merged? Yes. Okay. Personally, I think schema is the most important thing. Schema's the most important thing, okay. It seems, okay, so that was one vote for what I think is just instantiating cloud events easily in code, but there was an additional comment in there. With the version, with you. So is that nine? Yeah, with the nine, exactly. Yeah, I would also see that as a first code accessibility there. Okay. And I wasn't able to see who made the comment around schema, why that should be first. But I'm curious if you could follow up with some additional details as to why you feel that way. Yeah, sure, if you have the schema in there, this is Scott, by the way. You don't necessarily need the easy in code part because you can easily look at what the meta is supposed to look like. Like you know the shape of that event. And that gives you things like defaulting and validation and programmatic lookup of what is actually in the message object. Yeah, those are good points. Scott, how do you, given this is just an MVP initial version, do you have any ideas on how we would actually implement this? So I've done a lot of JSON schema work for OSB. Oh, great. So I would assume something like that. You can also, using that, you could inject like form schema and things like that and generate UI so that you can have a producer that makes your events that you can test your application based on what it's expecting. Yeah, our company makes the serverless framework and helping out developers just generate events easily, test them easily, validate them easily is something that we really wanna solve because that's a big part of the workflow over there. So this definitely resonates with me. I'm not personally sure if that's the first priority I'm still leading toward is danshing and cloud events easily in code. But Scott, do you think this could actually work with JSON schema? I need to read the spec more. So let me get back to you. So I'm wondering what exactly is meant by events schema. Is it the payload? Is it the attributes? I mean the event context or what is covered? If I had a vote, it would be the entire object. Yeah, when we talk about the cloud events specification itself is kind of the schema for the envelope. And then here I think this was specific to the actual payload, the information it contains. We already have in the cloud events specification a schema URL, which I believe is focused just on the payload. Okay, I'm just wondering if there isn't already enough tooling around for taking something like a JSON schema and validating something against it. So is this really cloud event specific? You know, what we put in that schema I think will be somewhat cloud event specific, but in my opinion, being able to leverage anything that's out there in the ecosystem that's already popular and solves this problem really well is definitely in our best interest. I would say it's probably not specific to the spec, but SDK might be as a helper. Obviously, there's an art of not overloading the SDK with tools and features, but it might be worth adding just as a helper. So I'm leaning towards number one as being my number one pick, but Scott, I would like for you to be able to look at number two and come back with a proposal for what you think the event schema would look like. Yeah, sure, I can do that. I'm gonna echo what Mark said. I really like number two. I just would love some clarity as to how we could actually get that done, whereas number one seems like an action item that people can kind of go run with. And then maybe number five, actually receiving the events. Yes, receiving event cloud events easily in code. Yeah, I'm not sure where to put this. I guess would this be like a number, a number three, a separate item? Maybe number two, I agree like schemas is important, but not the number one important thing. And you think this is, I have to confess, I'm still trying to figure out what they're trying to capture in this. Yeah, isn't there receiving a little bit related also to the actual implementation? Like you say something down there in your proposal with middleware from a note perspective, but if you transport it to other languages, you could completely have different mechanisms of actually receiving them in a system. For instance, we have a Java API that basically implements the spec of one. That's just a very tiny jar file. It is easy to combine that with Java based eventing. So I can just very simply create observers using some Java eventing framework, then I have a way to actually receive them in my system. Right. Yeah, I think there's some language specific use cases for that which are not, you know, general things, but should be concerned of SDKs for different languages for like things that, you know, can deal with events in different languages that are not general but language specific. That's right. That's gonna be a challenge we deal with as we go to implement all this functionality across the languages. Could we rewrite this possibly? Would this be a little bit clear? You know, from what I remember from your own specification, unfortunately he's not on the call, was that he wanted a way, he wanted simple getters. So it kind of follows these two things. And what you get are, you know, an instance of a class or something with a simple kind of getter and setter method so that you can get data out of the event pretty easily. That's how I read it. Maybe we could rewrite it to say something like getters and setters for CloudEvent instances. I'd actually make those simple with a one. Yep, I agree with that. And it's really, what is the API look like within SDK and part of that is do you have getters, setters, et cetera? Why setters? Isn't an event something that is immutable? Well, if you're creating a new event. Yeah, yeah, okay. I have a builder for that then, okay. But in my Java example, for instance, there is an interface that just defines the different and they create it from the builder. So I have the event itself immutable. Right, I mean, that's an implementation. Yeah, right, language specifics, okay. You know, until an event is actually emitted, then you should be able to modify it. Yeah, yeah, this is also, this is something that's being discussed and has been discussed for many months within the Cloud Events Working Group. What can be changed? What can't be changed? And I don't think we have a definitive answer yet. Largely leading towards immutability as much as possible, of course. But then there's a few different parties that interact with events potentially along the way and giving them the opportunity to set information. For example, middleware. Should middleware be able to kind of put some information in the event or modify anything? That's a point of contention within the group. Okay, pretty straightforward so far. Can you remove number nine? I think you encompassed that number one. Yep, number nine is gone. Okay. So for me, number four and five. Carl, what was that? Carl, it sounds like you dropped out for a second there. Oh, sorry. Yeah, I'm having some electric work at home. So my wife will be behaving well. Let me just switch to cell phone. So I was going to say that number four and five are equally important to me because they define how I'm going to consume events and how I'll be able to receive them or create new Cloud Events from non-Cloud Events. Not events that are not Cloud Events yet. So I would say they're both really important to me. So I'll put them both as the next next item. Well, I sort of feel the same way. Okay, but before we add these in, does anyone have any other thoughts on what number three should be? Doesn't sound like it. I guess to me, what I would value most is something quick and easy from an existing, that I can incorporate into an existing platform, either Azure Functions or Lambda. So whatever gets me to that the fastest is what I care about. Even if it's a prototyping and being able to give it to some people to say, how does this feel? I'd actually say number three should be number two. Okay, interesting. So in other words, I think that we do have some questions about the schemas and how that would interact operate, but assembling Cloud Events from various transports and encodings is pretty fundamental for being able to take the actual event and getting it into the system. Yeah, I certainly agree with that as well. Okay, I think that's a good point. And by the way, I know this is set in stone. We're gonna take this and propose it to the surplus working group on Thursday. It gets some feedback from them. Just curious, Mark, what do you think our first step should be on this priority, assembling Cloud Events from various transports and encodings? Well, we need, it's really understanding the scope of what that truly means. Is it taking an input stream? Is it taking a blog of data coming in, say, HTTP and being able to parse it, et cetera? I don't have a good answer for that. Yeah, that's what I'm trying to get from you, but, because I don't have the answer either. So you take a MQP, more of a binary protocol coming in, we know that we need to transform it and it's probably on a protocol basis, but it's gonna be very specific to that. But it's gonna be very specific to that transport. So we need, I'd say, identify the transports, which are the ones that we are currently defining. And then look at what would be the generalized decodings and encodings that we do for each of those. And the transport specifications that we have currently, it's HTTP, AMQP, NATS, we also have a webhook specification. Right, yeah, that's true. Do you know what the status is of that? I don't. Okay. You also have MQTT. Oh, yes. I was just pulling up the site to make sure I didn't forget anything. Okay. But again, so why would we do this? And it's primarily to have consistency into gain adoption of cloud events by having an off the shelf. Here's how you would implement a name, QP source going into cloud events, into a cloud event. Yes, that's right. Okay. Yeah, we just need further clarity as to how we're actually gonna go about this, which we can present to the working group on Thursday and get some feedback. Okay, we have four priorities so far. Let's spend the next couple of minutes, just maybe sorting the last four items here. I think one of them we already covered, so number three. Does anyone have any feelings on number five? The fifth priority should be, I think some of these can also should be bullet points. So generating mock events from a cloud event schema, that's, I believe that's a sub point, number three. And you could also say that on number one, we would want to be able to test it. And part of that test would be creating, and encoding, decoding, et cetera, a lot of events. So in other words, we would need mocking of events for test purposes there. I agree. Do you think that's a bullet point in number one, or is that its own? It's a bullet point. Okay. Mocking of cloud events for the test. Okay. Last, we have cloud events, extension add-ons and modules, and then configuration extension for adding middleware, the SDK can use to publish events. All similar, isn't it? Yeah. So what if we put cloud events, extension SDK, add-ons and modules is number five, and then the middleware has a simple point of that. Sounds good to me. All right. We got something. Cool. Okay. We have 10 minutes left. Let's see if we can break these down into cloud events, SDK versions. We've got a version 0.1, 0.2, 0.3. What should we put in SDK version 0.1? All right. Question first, which is, I assume that these versions are independent of the actual cloud events back versions? I believe we're probably gonna have to... Decouple them. Increment the, well, yeah, I guess so. Unless we decide just to increment the version every time the new specification comes out, and we update it. We could start out of the gate and have a version awareness built into the SDK so you can always be backwards compatible. So you ask the SDK, generate me a vo.1 event, and it spits that out. Yeah, I love that. No, no, no, no, no, no, no, no, no, no, no, no, no. And these milestones could be release candidates or alpha, beta, whatever, so that, for instance, the first alpha version or first beta version of version 0 would be, for instance, item number one, compliant with the specification 0.1, and so on, that 0.2, or would be then like the next release candidate matching the same 0.1 specification. Is that something that could fly? Perhaps. I like the idea of being able to work with the different versions of Cloud Events. It's going to increase the amount of work we have to do, of course, but it is something that people are going to want. It almost sounds like a totally different priority to me unless this is just baked into number one. I think if you build in that functionality into the library to start instead of try to add it later, it becomes easier. Yeah. And then people have to follow that pattern versus try to shim it back in once we've passed that point where it's non-trivial. Yeah. Okay. Do we think this is a totally kind of separate priority? It's probably a bullet point on one. Yeah, I agree. Okay. So in that vein, you could get the SDK to have some sort of negotiation where you can ask it, what's the biggest, or what's the compatible versions it produces. And then you can follow correct JSON semver with the SDK. I guess what I'm trying to say is that maybe the version doesn't really matter but the milestone, like an abstract number, there could be multiple releases between each milestone. Oh, yeah, right. These semver versions. Okay. Yeah, we'll present this to the working group and we'll get some feedback and see. How they think we should handle all this. All right, so putting this into milestones, how do we feel about just putting number one as Cloud Events SDK version 0.1? Yep. Like the two. So it's giving us a good quick start. Yes. Yes, yes. Do we want to bound the languages that we would support for the 0.1? And it doesn't that we have to name those languages but yeah, we want to support three languages. I'd love to do that personally. I think we're subject to the voluntary effort that we'll have kind of on hand. So. Right, I'm just thinking about ensuring that we're going down right now. We could implement in the same language but it wouldn't give us as much data about usability or how you would encode it into other languages. Okay, well, how about we just set a goal for three languages, supporting three languages? Okay. We'll see if we have the help to make that happen. If we do, fantastic. Okay, so what if, because we only have four minutes left, what if in version 0.2 we put assembly cloud events for various transports and encodings? Any objections? And these are, this gives us some sense of priority. Obviously there's, each one of these things could be a lot of work. So we're going to have to put some limits on this. But at least it gives us some sense of priority. We could present this to the working group, get some feedback. And then maybe cloud events, instantiate cloud events easily via event schemas. Can we put that in 0.2 or 0.1? Or should that be 0.3? I think it'd be interesting to get more scope on it to 0.2. Yeah, let's put that at 0.2. Cause it seems like something we could lean on for, we could lean on other popular tools to help implement faster. However, of course, all these things I think we need to work clearly to find the scope. But at least we've got some priorities. We've got some areas where we, which we think we need to focus on first. We'll present this to the working group on Thursday. At the same time, I wanna ask, there's a few people who've already started like Mattias and you guys over at VMware, you've already started designing some cloud events SDKs. Are you interested in continuing this work within a specific language? Yeah, for our case, for sure. And Mattias, you're doing a Java implementation, correct? That's right. Yeah, for dispatch, we're doing go. Okay. Yeah, I'd love to work on that within a cloud events group. And it goes without saying that I would, I assume we would put an applicable license onto it and put it into the cloud events repo. Yes. Does anyone have any objections to doing that? Well, I think in order for it to be a quote unquote official cloud events SDK needs to be part of the repo. Yep. I'd also say on the assembling cloud events from various transports and the coatings on 0.2, perhaps we could say implement at least N number of those transports and N to be decided, meaning, do we just implement one of them? Do we implement all of them? Yes. Okay, I'll put this as a comment, a quick comment. But we only have a one minute left. We have three languages. We have Red Hat working on Java, VMware, Dispatch working on Go. Our company would love to contribute to the JavaScript implementation. Is anyone gonna work on any other languages? Didn't someone already start a Python? Oh, someone did start a Python. If I remember correctly. Yes. I'll add them. I'll add them to this later. Cool. We've just had the time limit. So we've got a good sense of priorities here. We'll present this to the working group on Thursday and we'll have a longer conversation around this and hopefully narrow in on a more clearly defined scope for some of these SDK versions. Okay, in the meantime, before we wrap, does anyone have any other comments or major outstanding questions? No, thanks for putting this on. What are next steps? We're gonna talk to, we're gonna present this to the Cloud Events team on Thursday and then set up a subsequent call. That's correct. We haven't had a weekly call as of yet. We're going to pitch, we'll pitch this to the working group and figure out how to move forward based on that conversation. Probably we'll schedule another call in which I'll reach out to all of you. Great. So I grabbed the Python version out of the Manlin list from GitHub and put it into chat if you want that. Fantastic. Thanks, Mark. All right. Okay, everyone, chat with you on Thursday. Thanks for your help. Bye-bye. Bye-bye, guys. Bye. Bye-bye. Thanks. Bye.