 Hey Vlad. Hey John. Hey, good morning. How's it going? Fine. That's good. Hey John. Good morning. How are you this glorious Thursday? Thursday. Yes, it's Thursday. Don't good, don't good. Hey Vlad, I've been asked you just, I'm just curious, where are you actually located? I mean, Bucharest, Romania. So it's evening actually, but yeah. Cool. Okay. I was curious. I love it because I can easily fly everywhere in Europe or Asia. Right. Okay. Hey Ginger. Hey Doug. Hey and Tommy, are you there? All right. Thank you. And Heinz, are you there? Yes, I am. Hello. Oh, hey Eric. Actually, maybe a really short call. I didn't notice any updates to the, so I'm not sure how to interpret that. Hey Kristoff. Hey. Yeah, I noticed you this time. The next three weeks, I'll be on vacation. So I'll mark you a vacation next three weeks. I'll mark you on the attendance thing for that. Thank you. And Doug, are you there? I am. Good morning. Hello. Hey Aviar. Hello. There's someone in the zoom with an idea of, I can't tell what's an L or an I, then B-E-R-K. If you could do me a favor and paste your name into the chat. So just so I can mark your attendance, I appreciate that. And hi Klaus. Oh, Lucas. Hey Klaus. All right, Lucas. Thank you. Hey Jeff. Hey. Oh, hey Colin. Hey Doug. How's it going? I'm good in yourself. Pretty good. Pretty good. Mike, are you there? I'm here. All right. And Ryan. Yes, I am. Hello. Excellent. Hello. We'll just get started at three after. So just get that one. And hey William. Oh, type. Kind of weird. There's no Clemens. It's unusual. Let me go ahead and ping him because I like to get an update from him on a part of the doc. If he's not around, I can do my best to speak to that. Oh, cool. That'd be great. Okay. Did I miss anything? I think I had for a bit, right? Oh, there we go. Mark is running. Hey Mark. Oh, Mike. Hey Doug. Hey Mark. And Lionel, are you there? I'll be bailing in a little bit for that other presentation on Cloud Events. Yep. Thank you, sir. Hi Doug. Hey, got your Lionel. All right. It's three after. Why don't I go ahead and get started? This is Mohammed, by the way. Oh, Mohammed. Cool. Thank you. I missed you. All right. Let's do this thing. Excuse me. In terms of AIs, I did reach out to a couple different people in the CNCF organization, in particular Liz Rice, who tears up the TOC. And she said it was okay for us to send a note to the TOC as opposed to a formal presentation, just update them on our status. So Mark and I are working on that. If you're really, really interested, you could look at the tail end of the situation discovery doc, if the rough draft they're working on. But I don't think there's anything too controversial in there. So once Mark and I settle on the exact wording, I'll just send that out as an email to the TOC. And I'll probably BCC one of our mailing lists here. So you guys can see that when it goes out. With that, community time, anything from the community that people would like to bring up moving on. Kukani you. So I did create a planning doc just to gather all of our thoughts and activities there. So I bring that up here. So a couple of things. First of all, if you are planning and going, please add your name to the list here, just so that we can keep track of it for face to face planning purposes in terms of making sure we have a big enough room. And also, we will be having a kiosk if they ask me anything kind of booth thing. And I want to know who I can hit up for potentially manning that booth. So don't use this as an excuse for not putting your name there. We will leave out here. So please. Okay, so for the 35 minutes session, I'm still trying to find out from the workflow guys, who's going to be presenting there and what their abstract is going to be. I think they've been busy or sick or something. So I haven't been able to sync up with them. But the current status is a five minute quick update on cloud events, followed by the bulk of it on the workflow stuff. Okay. Now for our intro session, we agreed to a quick update on cloud events and then an overview of the subscription API. I don't mind doing the cloud event stuff. And that's someone else really wants to do it. But if you do either want to do that or the subscription API spec, just put your name here. Just because you see a name in any of these things, don't hesitate to put your name if you really want to do it as well. This is just for the list of people to choose from. And then we'll figure out who's actually going to do it later. So don't be shy if you already see a name on any of these spots. On the deep dive, here is the abstract that Scott gave me that I sent in anyway. And he's volunteered to be a speaker there. Given it's a hands on lab, we probably don't need too many speakers per se. But if you do want to join Scott on the stage to talk about stuff that'd be great. However, we will probably need several people to help out to walk around the lab to help the actual participants do stuff if they get stuck. So we will need as many people down here as possible. So please think about adding your name here as a lab helper. And as part of this, we probably also need to decide which SDKs we're going to focus on. Is it going to be just one to keep it easy for us maintaining this stuff or our presentation perspective? Or do you want to potentially have a couple of different ones people can choose from? No decision on that yet. But be thinking about that one. My plan there is, I want to set up like a few levels of like there's a hello world and then there's maybe something a little more complicated and then receiver and so on here. And then implement that as references in so sort of GitHub repo. And so people can pick their language and then try the exercise and they get help and then they can cheat off the actual version of the source if they want. Sounds good. Vlad, your hands up. Will everybody use their own laptop or how will this be? Yeah, it's bring your own laptop. Yeah. So when I get closer, I need to remind myself to make sure that I tell the event organizers to update the description to here to make sure it's perfectly clear that if you're going to attend this session, you really need to bring a laptop. Otherwise, it's not nearly as exciting. Right? Yeah, I was thinking like a five minute intro and then 30 minutes to kind of walk around the room and help people go through the exercises. Yeah. Okay, any other questions about that a little bit? Okay. Now question for you guys. I did confirm that we will have an answer bar ask me anything kind of a thing, which is the booth in one of the big halls there. And apparently there are three different options we could do. We can do dedicated kiosk all to ourselves, but it basically means someone has to be there full time or has a man full time, I should say. The other options are either halftime, dedicated AM or PM, or they describe this one as shared kiosk staff a few hours. I didn't know what that meant. I'm assuming it means more like it's just sort of random, whatever people are available, they stop by kind of thing. Not 100% sure. However, I'd like to know from you guys how you feel about this. Do you want to try to staff it full time? Do you think there's going to be enough interest in people from the audience? Because I can be the nag to try to get everybody to sign up if want to do full time, but I don't want to pester people if everybody thinks it's too much. Any preferences? Scott says halftime. Anybody else have a preference or opinion? When you say full time, do you mean full time throughout the conference or just for the first day? I think it's full time through the conference and here are the hours up here. So it's a non-trivial task. I'd say look to staff it during any of the parties or other bigger events that might be occurring within it. Okay, that feels a little more towards like the third option. I'd say this is gender. Nat said this last at the San Diego one and I will say the first day, if you're doing it all the whole time, first day is a very, very long day because you have the regular hours and then you've got the sponsor showcase, so the FYI, it's a very long day. Was there a lot of traffic? Thankfully, we had a lot of traffic but Derek was also in the keynote, so I think that helped our traffic. With regards to the other kiosks, I think Prometheus was right next to us. They had quite a bit of traffic throughout the whole conference. I couldn't really see the other ones as much. I know Fluent D was next to us and they had a booth the whole time but I will say that they didn't have people there the whole time, even though you're supposed to. What they did is if you only booked for certain hours, they would come out and switch the signage. Whoever the staff is that would do it. I don't know if it's CNSCF staff or if it's the conference staff, but they would come out and switch the signage. If it's cloud events for the morning, then it would have a cloud event sign and then if it was somebody else in the afternoon, they would just change the sign to a different project. Okay. Well, thank you. That's good to know. Yeah, but it was, I think it was very worthwhile for sure. So based upon your experience, just to put you on the spot here, if you were to choose of those three options, which one would you choose for us? I probably would pick part-time if the people that are attending the conference want to go do anything else. Just because, like I said, if you're supposed to staff at full time, the CNSCF does want someone there that can speak about the project pretty well all the time. Right. Let me say part-time. Do you do that option two or three? I would say two. Three is kind of weird. I'm not quite sure about that. Yeah. Okay. Vlad, your hands up. Thank you, Jinder. Vlad, your hands up. Yep. Can we post a schedule or something if we choose the second or the third option? I remember in San Diego, I wanted to chat with somebody at the booth and there was nobody there. It was unclear which were what. So having like a public timetable or something, and I don't mean public in the sense that in the working group. I mean public, like on the CNSCF website, SCAD whatever, that would help a lot. I can take an action item to ask about that from the staff. They do have that on the schedule. And so if you look at the schedule, it will have something like meet the maintainers or something like that built into the schedule. And it'll have your project and it'll show when the booth is staffed. I did not know that. Sorry. No worries. I just know because I saw it on the schedule when I had to be there. Yeah. Okay. Personally, I'm a little more towards number two just because this third one just confused me and it seemed a little too random for my taste. So I'm leaning a little more towards two. Scott, I know you said two as well. What do people think? Landing on two? Anybody have an objection with that? Well, I guess the only question is, is it always AM or always PM? Because otherwise I don't see how that's... Yeah. Maybe we can do one day and one PM in case people are going to have some flexibilities. So we have a little, I don't have to sign up till February 14th. So I can take the action item to find out a little more detail, whether it's, if we say AM, it's always AM or do we have to pick AM PM per day? I can ask about that. Good question. Oops. Okay. Cool. I can do that. Okay. Let me think of anything else. So I think we'll be able to get a room for the face-to-face meeting, but they won't be able to tell me until February 14th, which isn't that big a deal if you are already planning on going. However, if your travel approval, travel plans, whatever it may be, are contingent upon us having a face-to-face, you may not find out until February 14th, which I think is within that, right around that four-week window for our governance talk of announcing a face-to-face. So just be warned. You may want to get your travel approval in now and maybe, not necessarily lie, but tell your manager or whoever that you think there will be a face-to-face meeting. We just, we can't know for sure until then. Okay. All right. Anything else relative to who come we need to talk about? You can always say that you'll need Doug face-to-face. That's always exciting. Yes. I'm sure they'll get everybody on board. Yeah. Thank you, Mark. Can we get a room outside of the conference if we have to? I'm sure someone has an office around Amsterdam. That is definitely a possibility. That would make it harder though, because it'd probably be, it probably had to be more after hours then, which makes it a little bit more difficult to get our way together, but we can definitely look at that. Yeah. Yeah. Okay. So let's hold off and see what they say. Like I said, I think it'd be very odd for them not to be able to find a room for two hours, but we'll see. Okay. Anything else relative to the face-to-face? I'm sorry. Impressive. Okay. Vlad, I assume your hand is old? Yeah. It was old. Okay. Cool. Okay. I think we already talked about all these things. That's good. All right. SDK. We did not have a meeting last week, so nothing to talk about. I believe we will have a meeting today, right after this one's over. So anybody on the SDK side of the house, please be prepared to join. Kathy, I believe, is sick, unfortunately, so she's not on the call. Do you have anybody else from the workflow subgroup on the call who wants to give status? No. Okay. In that case, in terms of issues for cloud events itself, these are still being worked in the background, I assume. However, this one is new. I don't want to necessarily talk about it too much here other than to poke people to take a look at it, because it's a question about serialization of JSON. And I know that we talked about this in the past, and I just could not remember the definitive answer. So I was hoping maybe like Scott, since you're obviously heavily involved in the go-long SDK, maybe you could take a look at this and give your take on whether there really is a problem or not, or if not, why it's not a problem. So that's okay, Scott? Yeah, I'll take a look. Okay. Appreciate it. Thank you. And of course, anybody else is free to look at it. I just know, I think Scott's played in that area, that's why I was picking on him. Yeah, the spec is a little loose in that area. Yeah. And I know we went back and forth, I think, a man a couple of times. Okay. Anything else relative to the cloud event spec itself before we move on to the new spec? All right. Moving forward then. Okay. Since Clem is not on the call, Mike, would you like to update us on the status of things? I don't have any major update to provide other than the comments in the doc. I'm trying to get everybody, I propose the time tomorrow to talk, right here back from everybody. Okay. Unfortunately, I did not notice very many edits really at all in the doc this week at all. So that leads me to believe we may not have anything to discuss. And we have a very, very short phone call. So let me open this up. Are there topics on the spec that people want to bring up at any scope level? Hey, this is Ron. Yeah, I can just confirm that. Unfortunately, for the subscriptions part, majority of us had a combination of heavy travel schedules and being sick over the last two weeks. So we didn't meet this week, but we do have a follow up on Tuesday. So we'll hopefully have a more meaningful update next week. Okay. Just dead accuracy. Was Clemens one of the other sick? No, I believe it was Kathy and myself. I know Clemens has a pretty heavy conference schedule this week and has been doing a bit of traveling. Okay, okay. I was going to give him a hard time. But okay, if he has travel plans, then I can't avoid that. Okay. Yeah, go ahead. If we have time. So last regular call, we also talked about the subscriptions on sort of the back propagation of a subscription up to the original publisher. And what Clemens is not on the call, what he said, it's a difficult topic. And he kind of wants to push it back and I thought a bit about it. From my perspective, it's not so difficult. So I don't know if it's appropriate of not stop me if we discuss in this detail now. But my fault is it's actually not so difficult because you have the filters and you just take all your filters, you propagate them up one step. And then the other guys can do what they want with these filters. If you apply filters on your events that don't apply to events, it's fine. So I don't see where he thinks it's so difficult. Anybody want to comment on that? I don't have an opinion right now myself on that. I'm tempted to say that might be a better discussion for that other phone call or to wait until text appears in the spec to comment on it. That's just my initial reaction. Yeah, so I have been thinking about this also quite a bit. So that's also why I added this eventing domain section further down. But I also agree that maybe in the other call we can discuss it. Do you want to discuss it now? It's up to you guys. We have nothing on the agenda to be honest. Depends really. I mean, I brought up this abstract model of eventing domains because, I mean, there can be different messaging technologies behind. I don't know, Christoph, what scenario you have in mind exactly. So if it's also about using different protocols, so then you might have something that's bridging between different eventing technologies. So if you're propagating a subscription upstream, you might need to create things like queues and then delete them again if the subscription is deleted. I don't know. Yeah, could happen. I mean, maybe first we can discuss if we want to really have this discussion right now. I don't want to keep other people on the call and board. I think I won't be able to join the call on Tuesday, but I can try to make it. You could send a note to the mailing list to get your thoughts down on paper for people to read it. Yeah, that would be an option. Or, I'm sorry, just add it straight to the dock here. At least, because you don't have to wait for the subgroup to add comments to the dock. You can add your own, just to make sure it's out there for people to think about. Okay. And by the way, Christoph, it would be great to meet you on Slack. I mean, we're in the same time zone, I suppose. So one of the few guys I can discuss during the day. Okay. I'll try. I'm pretty busy with work right now. Okay. I'll try to join the Slack channel. Okay. Okay. Anything else you guys want to talk about? Colin, you can come with me. Yeah, just with the eventing domain. I mean, I think you get a lot of this stuff for free with most of the protocols. And this looks like it's trying to address the limitation you have with HTTP because there's really no central server. So, Bo, go on. Okay. So that was not the intention. So actually, we are working with an MQP broker below this. So the reason I wrote all this is more to establish something like a control plane for the eventing aspects and hide the messaging bit more. So it's not really supposed to be a new broker or something. Oh, yeah. Yeah. I wasn't insinuating that this would need to be a new broker. Now, I get that. I was just sort of stating that with all the protocols listed, and I alluded to this in a comment as well, it looks like we've got a real discrepancy between the behavior of the HTTP protocol and the others, which are broker-based. And what I was just saying is this eventing domain is very, very easy with a broker-based protocol, right? So MQTT, Nats, whatever. But then when you get into HTTP land, this becomes actually very difficult. And I see the problem you're trying to solve. I'm just sort of stating that there may be more here than this could get into a very deep pit. Okay. Yeah, I see. So yeah, for HTTP, as it is usually point-to-point, I agree that's more difficult. So an extreme example of an eventing domain would be just a single, I mean, a point-to-point connection. So you wouldn't then have a lot of producers and consumers, but just a single one and combine them then by a link, basically. And then it wouldn't really be really a dedicated domain or something. It'd be just hidden inside the producer and the consumer. You could also think of it that way, because you would still establish something like trust between those two. So yeah, it's meant, I mean, there are a lot of messaging products and also services and then the cloud providers. And it's true. It was more with those more PubSub-oriented services in mind. That's true. Yeah, I think it's a good idea to call this stuff out. This is good. Okay. Anything else? I left a comment on defining a goal around how consistent we want to be across protocols. So one thing I really, really like is when products just work out of the box. And I know it's a really lofty goal, but it would be great if we could provide some guidance around same defaults so that you can just switch between MQTT and NATS or MQTT and HTTP. What have you with minimal configuration changes? And setting a goal to this would help inform what this wire protocol might look like and maybe even bubble up to the API. Sounds reasonable to me. Is there actually text you can think of to just stick into the spec right now that the other sub team may be able to pick up and grab? Not off the top of my head, but I could take a stab at it. Yeah, but I would say do so. I mean, it seems reasonable to me. Okay. Anybody else want to comment on that? I know Klaus, you're commenting in the chat. Anybody else? I think everybody wants easy. So that's good. Oh, I don't know. Maybe Vile wants to vote for Harvard. Okay. Any other things you want to bring up, Klaus? Well, yes. It's not really about the subscriptions. It was actually the issue I opened more than a year ago, I think, about the nested events. So I've still got that action item and I'm honestly a bit clueless after our last discussion. So originally I brought it up in the SDK call two weeks ago because I thought it was just more or less an implementation detail in the SDKs. But the interesting enough, the discussion brought up that it's different. So as you can see, I brought this up in February 2018. So it was even before we had 0.1 of cloud events. And I think for me at least this nested event case is not really relevant right now, but still as I brought it up and it was an interesting discussion. So the idea is, we had the idea, I think, in the discussion further down. Doug, you proposed, I could just write an example where one event, like a structured encoded event, would be nested inside a binary. And when I tried doing this, I ran it to the problem that we determined by the content type that what the event in that message is. So doing this, what is shown here, this example is not possible and it's also not really that came out in the discussion two weeks ago, really against the spec as we say that. No, I think it was against the spec. Yes, that's what I said. Sorry if I somehow didn't express that clearly. So exactly. So the idea of the spec and that I wasn't aware of that too at that time is that even if you do structured encoding, all the attributes from the structured encoded event can also be replicated to the header. So this case that you have one event in the header and another one in the payload is not really possible, at least if you use the normal content type of the cloud events plus JSON. So I really wonder now how this could be solved and or if it needs to be solved. I mean, could also be just some note somewhere. I think we could work up an example in the goaling SDK where we make application JSON plus cloud events and they would interpret it correctly. Yes, so I've been reading a bit in this about this media type specification, this RC and so on. Plus cloud events is really strange, I think. So I mean, the plus something part is supposed to be a structure encoding part and I don't know, see cloud events in the line with JSON XML and the others somehow seems to be strange to me. But yeah, so just I'm just interested to hear some more opinions on this actually. I just read the issue for the first time. The thing that comes to mind there is in that API gateway issue is causality that there might be an independent event from the API gateway. It could reference that it is caused by the other event. Yes, but isn't that really just talking then about maybe adding additional attribute to do a relationship? Were you talking or does that directly affect the nesting aspect? I mean, I would question if you need to nest events or not. Yes, I said I created that issue in the beginning when I still was trying to make my mind about all this eventing and by now on our end, I would say we definitely want to avoid this nesting. But one example where I saw something like this or where it might occur is actually in canative eventing. With some of the sources, I think like the Kavka source, I think they create their own event types like Kavka event. And then they already get a message from the log that already contains a cloud event. I think then you would have something like a nested event. But I still think that it's more like an accident, not really desired. Yeah, I think that particular case is about being canative. Okay, nevertheless, if you rely strictly on structured encoding, you could nest events and some SDK that gets one structured event nested into another one. And for some reason would like to transcode it to binary on the top level would kind of run into this issue, I guess. So I'm trying to remember the phone call we had about this. And I came to recall you became the conclusion that this example here was technically invalid. And I think part of the reason was because these properties here did not match the properties here. And if these appear here, they're supposed to basically be a duplicate of what you see inside the body. Am I remembering correctly? Yes. Okay. The one thing that always kind of bothered me about that is I know that the spec says you can copy things up. But does it mandate that if, for example, C type appears here, it has to match what's in the body? It doesn't say that it says that the authority is the body. Right. The processor would just look at this and say it's formatted incorrectly. Okay. So well, or worst case scenario, he looks at these and says, because of this value here, everything's supposed to be in the body. So if I'm going to be looking at the body, I can just ignore these. That's right. Okay. Thank you. So would that then imply you can't do nested? No, you can. You just have to say the application content type is application JSON, maybe plus cloud events to signal that the processor that processes the body pops it into a cloud event. So flip those two things and I think it just works. It would work, but it looks definitely strange, but maybe yes. Well, just out of curiosity, what happens if you don't do the plus cloud events and you just do this? Is that? Yeah, that's valid too. That's absolutely. That is valid, right? You would serialize that as cloud event JSON structured object and it would just work. So Klaus, is the answer here to put something in the primer that says if you want to do it, as of right now, this is really the only way to do it? Yes, could test. I mean, we can test the Go SDK if it does it. I mean, if it receives. Yeah, I can add a test for this and we can add a custom decoder for the application content type or sorry for the media type of application JSON plus cloud events. Yeah. Okay. I mean, probably it's already wasted effort as probably it's not that relevant. Although actually thinking about it, you don't really need that. That's a hint to know what the format is, but it's really just JSON and cloud events doesn't really care about the opaque body. Okay. That was a bit my question. Why do we have to have it like in the spec? You have like the data and in the data, you can have whatever we want, including another nested event. So that's up to you if you really want to do it. But then you don't get all the transformation from one protocol to the other, obviously. But that's not up to you. So you can do it if you absolutely have to. Well, I don't see the value of adding the complexity of all this nesting into the spec. Okay. Yeah, I agree with that. Yeah. But I thought your Heinz you're looking at putting it into the primer just as guidance, right? Something like this. Yes. I mean, we can also just close the issue actually. Well, I think it's interesting. I mean, because I was just thinking about this is obviously this is one way to do it, right? You have structured around binary or binary around structured, but it might also be interesting to show a structured within a structured where I think as Christoph was just saying, this stuff doesn't appear here, but there's another cloud event in here. And then you have the content type up here and what that would look like. Yeah. I mean, in that case, you could choose cloud events plus JSON. But it's just that in the binary case, the content type is yeah, somehow used and yes, just special because of this binary case. Yeah. I mean, as I said, technically, we don't think we have to do anything, but I always think that if we come up with a question and we're the experts on this stuff, it may it's useful then to put into the primer for people who are not in our position. You know, even if it's just for informational purposes only. Okay. So yeah, I can add that to the primer. Then I guess the recommendation would be in any case to just use this application JSON even for the structured case. Otherwise, it would be really confusing. I mean, if you do one structured event inside another one, you could technically still use cloud events plus JSON instead of just JSON, but you must be there for a second because I think did you say that if it was structured, you can just use the application JSON and not application cloud events plus JSON? Yes, otherwise, yeah. I think closest is correct because I don't think it would round trip converting a wrapped message between binary and structured if it wraps a structured object because I think it promotes the content type. In that case, you get into the same situation of the above example. So it seems like primer text is probably in order if you're going to wrap cloud events. Are you okay with that, Klaus? Yes, I think so. Yes. Okay. Any other questions or comments on this one? Okay. Any other topics at all then about either the new spec cloud events or anything? Any plans to cut a new release of cloud events? Or is it just minor tweaks? I think we've only had one tweak, which was the sentence that says it was a draft, right? I don't think we've changed anything else yet. Did I miss something? No, I was just thinking about our ability to rev the spec independently of the version of cloud events, like the bug fix sem-verb section or something. I'm not quite sure what you're asking, but I apologize. I'm not following. We could still send 1.0 events, but the spec is 1.0.1, for example. Yeah. I'm trying to remember, did we say the spec version required how to be sourced? I don't remember if we ever talked about what would happen if we do a patch version, if this version would change. I don't think it would change. Because patches should be completely compatible. But they wouldn't have the new features. It would be 1.1. I think that'd be a, yeah. That's why I said patch, not minor. So what's your actual question then? I apologize. So if we do a 1.0.1, so like a declarative text in the spec, and we want to ship a new version of that because it's better, but it didn't change the API. I think off the cuff, I would say the spec version string itself does not change. Right. Okay, great. But that's just me. I don't think we have to actually send that in the spec, and maybe that's something we need to add, or we can wait till we get to it. I'd agree with this. I mean, if we have a typo and we fix it, and we really want to release a patch version, I don't see why a new spec version is relevant in any way to anybody who uses Cloud Events. Yeah, that might be something worthy of mentioning someplace in our primer or something that just so people understand our versioning scheme. I'll double check. I have this vague recollection. We may actually say something about that someplace, but I'll check. And if not, maybe I'll open issue just so we can think about it. Okay. Anything else people want to bring up? Okay. Did I miss anybody for attendance? I think I got all the people who showed up at the end. All right. In that case, we are done. Thank you guys. And if you were interested in the SDK call, go ahead and stand the line. We'll start that one up in about two or three minutes just so that people leave. Thanks, everybody. Thank you. Bye. Bye. Bye-bye. All right. Any topics? Otherwise, it's going to be a very short call. Scott, you usually have something exciting to say about the Go SDK line. I'm sorry. Go line SDK. Scott is taking a small break. You have your eyes on him. Interesting. You know, somebody always has to have eyes on us, Scotty. Okay. We'll wait. Anybody else have any topics they want to bring up? Okay. We'll wait and see if Scott has anything when he comes back. Otherwise, it's, we signed up to go to Kukan. Not too bad. So, really, are you able to actually see when he comes back? Oh, yeah. He needs to make sure he knows we're waiting for him. It's all about Scott. Yeah. Don't tell him that. He's a big ego. Yeah. I mean, you know, when he comes back and if we happen to be in the middle of a discussion, how terrible the cloud Go SDK is, then I'm sure he would be super excited to join the conversation in the middle, just throwing it out there. Yeah. Yes. Oh, hey, why are we waiting? There was that face-to-face meeting between Knative and Kata. What's the next step in that? I thought there's supposed to be a follow-on meeting. Has that been scheduled yet? I don't think it has been scheduled yet. There is a Kata call at, I think it's in like whatever, 20 minutes or 10 o'clock my time. So the next meeting slot. And I think there's some jatties about that. I know some folks played with the interaction with the K-native and Kata and seeing where it would kind of fit in. And this morning in the channel's working group, we also chatted about making sure that we start, there's the whole channel spec on sort of kind of what the channels look like. And there was some talk about making sure that in the spec, we do not assume too much of a push-based, but we also allow for the venting based, sorry, pull-based models. And so I basically wrote some folks volunteered them to go ahead and take a deeper look on what does that mean. Did you either hear of or take a look at the work that Alec is doing around Kata integration? I think you might have talked with Scott yesterday, but I didn't know if he pinged you as well. Yeah, he didn't ping me, but yeah, I'm aware of this. This is Islam. Yes. Okay, cool. Okay. So is Mr. Scott back yet? He minus five seconds. Scott, you there? I am back. All right. Thank you. So no one has said anything to bring up. I was wondering if you had anything to bring up from the go-language case out of things? I do, I do. We are going to go do a version 1.0 release. There's a bit of staging that's going to happen. Like massage the EPI a little bit. Some of the deprecated things are going to get removed, so we don't have to continue forwarding them along. And then we're going to start doing strict semper. Okay. So I haven't been following the go-lck for a while and now got back and looked a bit more into it. If I understand that correctly, so there are those two approaches right next to each other, the bindings and the transports. And yeah. So at the moment, the plan is we're going to do a 1.0 release that's going to capture the original method. And then because we're going to do semper, everything else in the repo is going to start having to become API compatible for changes. There's going to be a 2.0 release that drops the original transport implementations in favor of the bindings. Okay. So that's kind of where it's going. But the hope is that if you depend on a certain part of this, the SDK, you can do semper fuzzy match and you can stick with 1.0 if you need to, but it's going to be end of life in probably, I don't know, six months. So V2 is scheduled for around six months? Is that what I heard? Yeah. I think that sounds about appropriate. Okay. So the 1.0 release, if I get time, it's probably going to be cut next week. So before the next meeting for cloud events, it'll be 1.0 and semper. And then there's going to be an effort to go and migrate everything to the 2.0 implementation. And we've been coding this strategically. So there's pieces that are leveraged in the 2.0 implementation that get migrated out or copied out of the 1.0 version. So we're aware of the strategy. And then the other thing that's going to come is we're going to document the 2.0 architecture so that it's a little more clear what exactly we're doing and how to add a new binding, your own custom bindings and stuff. The goal is to get 1.0 walk down released for KubeCon and for integration. So this comes because there's been some people that would like to integrate with the SDK, but are unwilling to do this in the read me. It's like, by the way, you're going to break you willy-nilly. And there's customers that do not want to take on a dependency that doesn't follow center. So even though it's maybe not production ready exactly, there's still some stuff to figure out. We're going to lock the API down. Makes sense? Yeah. Any other questions for Scott? Okay. Any other topics you guys want to break up? You scroll down a bit. Are you joined this call because I was interested in Tim's question from the other week. So GoLang SDK, Superstable, very much evolving. What is super-involved and maintaining it. C-sharp SDK Clemens obviously uses it for Asians. Asian stuff is maintained, it's stable, so on and so forth. Do we have like a list of maintainers for the others? Should we do that? I'm starting to have some interest in health events, but a lot of people are a bit off by the state of the SDKs. Yeah, unfortunately, I didn't do my AI. I was supposed to poke the bottom four people in terms of who the owners are. I can't say who they are offhand other than I think Fabio might own the Java one. I was going to just take a look at the commits and see who did all the commits and poke those people to find out the status of these things. Well, maybe we need to have official leads that are kind of accountable for these things. That would be a good thing to document that someplace, yes. In the specific repos of you. Yeah, another AI for me that I'll forget to do. Thank you. Sorry. I was like praising CloudEvent and they were like super happy about it. They wanted to do Python. My first question would be why? Why Python or why CloudEments? Why Python? A lot of their app is already written in Python. They do all Python. Why not get with that? There's a surprising amount of libraries available for Python, especially they're doing a lot of lambdas. And Python is super well supported there. Whatever makes the money. Yeah. All right. Anything else? That's it. All right. I believe we are done then. Thanks, guys. And we'll talk again next week or run the SDK in two weeks. Have a good one. Bye. Bye.