 Hello dog, and hello everybody. Yeah, hey, hey, just like sorry. I'm trying a different machine. I need to quit and do something. Hold on a second. As long as you come back, it's all good. Thank you. Right, you can see my window, right? Yep. Yes. Okay, good. Let's see. Participants, where's my chat? Trying a different, just trying a different machine today. It's taking me a while to get set up here on last night. This is a new machine, or is this a, when you're just borrowing, just because you lost yours? Actually, I've had this machine for a long time. I just don't ever really use it. I decided I might as well try it. It has a bigger CPU and stuff, so it should be able to handle virtual conferences and stuff a lot better than my old one. My old one's kind of dying. Yeah, it tends to happen. Yeah. Okay, how are you there? Hello. Hello. Slinky. Hello. Hello. Yo, Tommy. Yo. It's DML folks. Scott. Doug, Doug, Doug. Hey, and Kristoff. All right. Hello. Kristoff. I'll get it right one of these days. Ah, Lucas. Yeah, I'm here. Oh, wait. Other one, right? Sorry. Oh, I'll take both of you. I see you both came up. Yo, that's good enough. Okay. Whoops. And then Manuel. Hi. Hello. Lou, are you there? Hi. Hi, good morning. I love the commentaries from John. Oh, man. So that's interesting. Kristoff, did you make that edit? Who made the edit? Yeah, I made it. Was it a suggestion? You have to accept it, I guess? Yeah, I just, I'm surprised it didn't show it as a suggestion. Why didn't it? Oh, there it is. Okay. Okay. Yeah, that was weird. Sorry for the complicated name. No, no, no, it's just I, normally it pops up as a little bubble on the right here, but I didn't see it right away. So that was just weird. All right, Klaus. Hello. Hello. Hey, Ginger. Hello. Jesse. Hey, good morning. Good morning. Christian, are you there? Yes, hello. Hello. Hi. Hey, Remy. How's it going? Good. Hey, Eric. Antonio, are you there? Yes, I'm here. Hello. So while we're waiting, Antonio, I think you never mentioned what company you work for if you want to be a sociability company. Thank you. I'm sorry, say it again. You're aware with who? No, no, I'm okay with any company. Okay, got it. Perfect. Okay, great. Thank you. Yep. All right, three after. Let's see, I got everything. I got everybody so far. Let's get started here. Okay, just a reminder, Clemens, you have quite a few AIs that are kind of building up there a little. Yes. Yep. Okay, community time. Anything from the community people want to bring up? Cool. Okay, we skipped the SDK call last week. Interop. I don't think there's anything on the agenda right now for interop, but maybe good, just have a five minute discussions to find out where people are relative to it. So we'll have that right after this call. Let's see. Okay, EU. I'm sorry. Kukun, I need you. Should we cancel the calls next week? I'm inclined to say yes, but I wanna hear what everybody else has to say. Probably won't be on the call. Okay, let me just double check here. Yeah, I don't think any of our sessions overlap, but do people want to cancel or keep it? Any objection to canceling? Because hopefully people will try to attend Kukun. I've got a couple of yeses. Remy and Manuel also, well, let's go ahead and do that. Oops. Okay. Okay, so office hours. I apologize. I don't remember who it was that mentioned it last week. I don't know. It may have been you, David. It said they may be able to participate in the office hours. We need to know technically as soon as possible. The deadline was technically yesterday, but they did respond back to me saying we had more people just let them know. So let me know. And if you are gonna join, so for example, Clemens and Klaus, please go to the RSVP link here and make sure you sign up. I'm not quite sure what happens when you do that. I went there and I got an email, but I haven't actually looked at it yet, but you probably need to make sure that they understand who you are so they can send you the invite to the Zoom call or whatever it's gonna be. Okay. And just let me know offline if you do want to join the fun. Okay. I think it's after my talk. So if you want more people, I can probably attend because I have to get up at 3 a.m. anyway. Okay. Yeah. It'd be great if you could join. Anybody can join. I just found out that I won't be able to join because it overlaps with a couple of the sessions that I'm doing, but I'll try to join later. That's my sessions are over, but we need other people there for, we could definitely be there. I think I'll be on the one on Wednesday, the one on Thursday. I'm not sure I want to get it twice in a row at like crazy time. Okay. That's fine. Is this both days or is this both days or just Wednesday? Whichever day you can do. It's technically both days. Thanks. Okay. And I guess I just ping me offline and I'll let them know that, to add your name to the list, I'll let them know about you, Remy. All right. Let's see. Team person on the call and I haven't heard from him so I don't know if there's any updates there. So before we jump into the PRs and stuff, any other topic to add to the agenda? All right. So Clemens, maybe we should wait for John to show up because he specifically wanted this brought it to the top of the list even though you have an outstanding AI. So anyway, why don't we go ahead and do that? Because he may have some questions on there. So let's skip that one for right now. So this one is another John one, but I think we can talk about it without him here. So he opened up this PR to modify the primer to talk about versioning of attributes and stuff like that. And we merged it into master. So the changes is approved in general. The question for the group here is whether this is worthy enough to go into a 101 as a hotfix or whether we want to save it for a 102. Does anybody have any opinions on that? It is just the primer. It's not the spec. No opinions. Does anybody feel like if we did this it would violate our rule of typos only going in as hotfixes? Obviously this is bigger than a typo, but it is clarity and just in the primer. The massive typo. Is that what you're saying? Okay. I personally, I don't have an opinion either way. I'm okay with it going in. I like clarity. And since it's not just in the spec, I'm okay with it, but. I'm fine with it for. It should be expandable. Okay. And Lance, thank you for jumping in there. Okay. So any objection to treating this as a typo typefix emerging into 101 as a hotfix? Okay. All right, cool. Thank you all. All right, Slinky, you are up. Would you like to introduce this one to people? Nope, I'm gonna go back over here first. There you go. Yeah. So this is just to make simpler the usage, more straightforward the usage of filters. So basically the filter today is an object composed by just one inner object. While I think it would be better to take this kind of approach where the filter is an object that contains the various dialects and dialects and the evaluation does the end of the results of these dialects. So basically this is just a shortcutting mechanism. Yeah, it's a shortcutting mechanism and it's, let's see. Yeah. Yeah. So it's the one I was talking about. It's simpler to use. Yeah. And where is it? Typo, there was something else, where was it? Yeah, no, there was a, no, I fixed the typo, but then yeah, this one. Yeah, just this one. I think there's one other spot you might need to change just in the pseudo schema, right? The, where is it? Well, I changed the open API? No, I mean, that too, yes. Why am I, sorry, in the wrong branch. Subscription. I think this needs to be a star. Oh, okay. Yeah, can you please link this paragraph in the issue? So. Yep. Thanks. Okay. Did we sync the, because we did the last work we did was really on the spec on the open API doc. And I'm not sure whether the spec is actually back in sync. I don't know for sure. I don't remember. Because I, Which set of changes? You mean that there's the shape of the filter stuff? We'll see if you can explain the change. Again, like the one off to any off? Because any off allows more than one. While one off allows exactly one match. Yeah, the idea is that you have a filter. Like, so we had a discussion about this and we'll actually land it in this place where you have one filter. And then if you want to have multiple filters, you use the any composition because you just introduce any composition here that's applied. This is all composition, not any. This is all composition. Yeah, I mean, it's, I think it's an, I've opened this PR because I think it's a necessary. It's a necessary to have that kind of data structure where you need to have all. And then inside all you have the filter and then filter exact and so on. But it could also be just a SQL filter or just like any single filter will be sufficient. Correct, he's just saying he's like an implicit hand around us. So you don't have to do the filter hand and then put these two under the end. He just wants an implied one. So it's a syntactical shortcut is what he's looking for, I think. Yeah, it's a usability change. That's correct. Making it simpler to use it. Does that make sense, Clemens? Not whether you agree or not, but does it make sense in terms of what he's trying to propose? Okay, so first level at the top level there's always an ant. That's what he's implying, yes. Can I see the change again? It's not just at the top level. It's at the filter object level. Which at the end of the day, if I can add something, at the end of the day, that's, I'm not sure if you know the open API, security requirement object, which has an end or semantic and it works exactly like that. More than having the all and any, which for them is end and or, they just differentiate between object and array. It's a bit, I think it's a bit more complicated than the system, but the fact that they have the end, which is just the elements of the object is simpler. So, let me say for the all filter, you also change that. So the filter entry, so now I have an all filter where each item was either a filter or an all filter or an any filter and now it is what? It's an any of. Well, to be honest, I'm not 100% sure the change the ID to the open API and I'm more than happy to review it again. But the idea is that any member, I mean, the filter object, which is not the filter schema that we have here, because filter schema is more like base filter object, right? The filter object with this change becomes a list of entries where each entry is a filter dialect and then it does the end between the all different dialects. So I think it'd be useful if we take this one step at a time without getting into whether the actual open API changes are right or not. What do people think in general about having an implied and or do people not like that and they want people to be very explicit and say and around stuff like this? So how did I do it all then? Like for me, for me, there's a consistent question. The simplest case is that you have, and that was the goal of it. The simplest case is you don't have a, you don't have multiple conditions, but you just won. And then you just put the filter in and you're done. So if you have a filter and at the SQL filter, you say filter, SQL expression, like you're a munch or you have a filter, whatever the dialect is and you put your own decision. And then if you have more complex stuff and that is exactly as it is in JSON schema and arguably also as it is in XML or any other compositions, you make up a bracket, which is the end or the all, which means there's an old composition where there's an ant composition and that's where you stash the other, the filters into. Now, like with this top level construct, we're now a special casing, a special casing all, while having a, and then any, the OR would then be a different construct. No, no, no, Clemens. It's not just for this top level. It's for every, for the filter object itself. Hold on a sec, Lucas, can you come here? I think there's some background noise with your papers shuffling. Lucas, you there? Yeah, hold on, let me do that. Yeah, thank you. Okay, go ahead, it's Linky. No, I was saying that it's not for the, what you think you misunderstood is that I'm not talking about only the top level filter. I'm talking about the filter object itself. And by the spec, the filter object is a map of dialect where there can be only one key value, okay? And what I'm changing is that I'm saying, no, in this map, you can have several dialects and we will do the end of the evaluation of this. How does OR work? OR works the same as before. But why are OR and AND different? Because it's for simplicity here. I think, I don't think he's getting rid of the AND, Clemens, if that's what you're thinking. Or getting rid of the AND, I'm just saying, if you need to define something simple like you wanna have just two filters and you wanna match both, then you can do this. Then if you wanna go complex and do complex any and all filter composition, you use all and any as before. But if you just switch back to the definition, I mean, you literally have an example here where you say there's an any off and there will be an all off in JSON schema. I mean, it literally has like, if you want to have all off, which we don't have here at this case, but that's exactly how JSON schema does it, right? You either have an any or you have a more off, which we don't have for the filters, or you have an all off. Like the structure in JSON schema, which people will presumably then be aware of, is exactly the same. Well, I can argue on that. Because in fact, a JSON schema is like the schema object itself is a list of keywords and the schema is an end of those keywords. So actually, your example is more distant from JSON schema than my example. Because if you look at the spec of JSON schema, again, it's every keyword is a predicate and the schema object is the end of those predicates. So that's at least, I mean, that's where I'm coming from. And that's why when I saw the spec I said, yeah, it's too much verbose for that, for doing the all. So your primary objective is to get rid of the all? No, no, no, I don't want to get rid of the all. It's fine. I'm just saying that. For cosmetic purposes. It's too much verbose. Clemente, he's not getting rid of the and or the all, whatever you want to call it. All he's saying is in cases like this, it's annoying to have to wrap it with the and, why not make it implicit? Okay, so he's getting rid of the all construct. No, you could still wrap with this within all is what he's saying, but you could also just have a list and the all is implied. Yeah, so then if we do this, it would strike the all. That is another option. Yes, it depends on whether you want something implicit or you want to force people to be explicit. I think that's what it comes down to. Because I would prefer not to have two constructs for the same thing. Why should we force people to one or the other? I mean, it's a no brainer to support that. So honestly, I don't see, I mean, I think it's no brainer to support it. And at the same time, you're just making it simpler for some use cases where for other use cases, it's just better to do the whole tree with all and any. Okay. Does anybody else want to chime in here in terms of how they view this? Is it a nice thing to do? Is it going to be confusing to have two ways to do something? It's the first time I've looked at the filter stuff personally, but it feels to me like and will be vastly, I suspect it will be vastly more widely used. And I like the idea of being able to do it explicitly where that does make things more readable and implicitly in the common case. So I haven't looked at the PR to see how it's achieved, but judging by the discussion, if I've understood it correctly, I'd be in favor. With a very, very low weighting, not having looked at the filtering at all before. Okay, thank you, John. Anybody else would like to chime in? I'm going to pick on somebody then. Scott, how'd I take your take on this from maybe a Knative perspective if there is one? I don't think we would ever expose this in like a top level resource, because it's too chatty, right? But I think something highly declarative that could talk to systems that consume this would be interesting. Right, but do you have any opinion on whether it's better to support both mechanisms or should we only say no? We're going to choose either implicit or explicit, but not both. Yeah, I would choose one way. Okay, thank you, sir. Anybody else want to chime in? Let me put it this way. Would anybody else like to raise their hand in favor of choosing just one or the other? Because I'd like to know whether Scott is alone and it's take on, maybe you better have one or more people are leaning more towards Slinky and John's view of nice to have both. I'm going to start picking on people again. In defense of what I just said, I think so because this is supposed to be kind of this fundamental API that the subscription APIs are using I think it's better to be more explicit than at that level of the API. So there's no confusion. How far would you take that? Does the, do you want to take it as far as to say, okay, let's be more explicit because it's a formalized spec. Therefore an implied and is not as good as an explicit and. Yeah, I wouldn't really want to put implied anything. At this level of the specification, right? Like at this level of the API, it should be very, very explicit so that you can look at it and really understand what it's going to do. Okay, let me pick on somebody who, okay, thank you. Lou, can you also comment on which one you'd prefer, implicit versus explicit? And in the meantime, Eric, do you have an opinion on this? I'm in favor of explicit. Not in favor of, wait, you're not in favor of explicit or implicit? Explicit. So you want it implied? No, no, I don't like implied. Oh, you don't like implied? Okay, I'm not. Okay, thank you. Eric? I don't have a very strong opinion. I kind of think that both could be all right, but I haven't looked closely enough to have a good. Okay, may I pick on one more person then? Klaus, do you have an opinion on this one? Yes, at first sight, I tend to agree with Scott, but I would have to think about the board tool. I would have a stronger opinion. Okay, I'll tell you what. I'm hearing both sides. Why don't we give people one more week to think about this since this was just presented today? I don't correct my wrong slinky. You don't need a decision today. It's not rocking you from doing anything major, correct? Yep. Okay, so why don't people give it another week and then if it doesn't seem like there's an overwhelming majority on next week's call, then we may just call for a vote. But please think about it. And in particular, if you can think about reasons why one or the other would actually be bad for people from a usability perspective or something like that to help sway people, I think that'd be really useful. Because if it just comes down to a personal preference, then that's gonna be a little harder to decide. And then, yeah, it may just be a flip of the coin or a vote kind of a thing, okay? And in the meantime, is this correct? Would it be any of, or I don't know Jason's game at all. I'm sorry, open API at all. Is this some, should it be all of, is there an all of? No, no, no, no, any of is fine. But I think, but any validator will probably stop at the first match. So I think this needs a bit of a rub working. Okay. Yeah, there are, any off and one off difference is having massive effects on the co-generators. And what they put out. So that's something that I'm certainly gonna go and check out this PR and check it against the co-generator stuff that I have. Because for the discovery, I've been building, I not only did I build the discovery piece, but also the subscriptions piece that is funding our service. And so this change will cause quite a bit of churn in my co-generated stuff. So I'm curious how that comes out because the truth that ends up in the code. And I think, so I understand where that goes, but I think the construct needs to look a little bit different. So my intuition is that the any off in a 9-2-25 that that's wrong. Okay. Go home. You have a week to sort of do the exploration. So that's good. I'll try that out and we'll comment because that's literally where I'm at right now. Okay. Slinky, your hands up. Yeah. What I want to propose you is that if we can agree on the spec change, what do you think if I do the schema changes in another PR and we figure out how to make the schema change proper for the code generators too? Because I think to make it working, what we need is that we need to have the filter schema renamed as base filter. And then the filter schema is the actual one that has all off of the dialects. And then each of those have have properties. Sorry. It has optional properties. So that's the way we need to do that. We need to make quite a few changes for that change. And so there will be quite a bit of churn. So I'm having the implicit option will, because the implicit option causes the filter object not to have a list. So this here is a pure, so this concept here is purely a tree, right? And so this new option will be a bit more difficult. So yeah, I think it would be good to go and split this into the text when it should be. And then experiment how this works because JSON schema, unfortunately, looking at it is not telling you what the code will look like. So in general, I don't have a problem with splitting it. My only question would be, is there any risk that we decide not to do this at all because the JSON schema or OpenAPI is too complicated and it makes the infrastructure too hard? I don't think so. Okay. We're ultimately just turning one thing that's just one object into a list. But then the elements of that list still follow very similar rules. So we're building a more complicated tree, if you will, in the worst case. Okay, okay. That's fine then, Slegee. I think if you want to split it, that's fine. I just want to make sure that we're not going to reverse our decision based upon the OpenAPI change. I can see the construct turning out in a way that the object that we're putting under a filter in the top object is actually the same object today. What is the all filter today? Because the all filter is an array of islands. So that is probably the exact object that we want to go and fit there. And then you go and so that becomes effectively the filter, this container that sits at that level into which we then fit the filters. I'm also going to take a look at that. Okay, sounds good, thank you. Because I have some, for the subscriptions API, I also have had a few, I think, tweaks that I still want to go and add, like I think there were some operation IDs missing or something. So I'll take a look at that too. Okay, cool. All right, so we'll hold off on the rest of it. And I can help. So yeah, just being me. Perfect. The problem with those OpenAPI specs is that because JSON schema is such a complicated thing, the code generators are very take-less when it comes to circuit constructs and for some languages like Go, it's the polymorphisms close them off and so we'll just have to go and try out how those things look in various languages and whether we like the result and make it somewhat dependent on tooling. I don't like that, but that's just what the state of affairs is with JSON schema. Okay, cool. All right, let's move back then to this one now that you're on the call, John. You would ask for this one to be on the agenda because I think you wanted to talk about it a little with Clemens, right? Can you? Well, you had said that Clemens was the, we were waiting for Clemens to discuss this. Basically, I would like this resolved in terms of are we getting rid of it or not so that when I publish a C sharp SDK version two, I don't include an extension that's being removed. So timing-wise, it would be useful to make a decision. I mean, I could preemptively remove it and then add it back in if we decide not to remove it from the spec, but it feels like it would be good to get some progress on it three months later. Right, so Clemens, can you bump this up on your priority list? Yes. Okay. I think what we wanted, I think what we landed was that there was still clarification missing in this, what the role of that is relative to whatever happens at the transport level, right? But we also, I think we also landed then that we didn't want to go and cut it. Well, I don't know if we actually came into a formal decision yet. I think you had some ideas to try to alleviate some of Slinky's concerns, but we needed to wait until we see that text to see whether that actually is true or not. Yeah, I'll promise for the next, oh, we'll cancel the next call, are we? Well, apparently. So I will get to this. I have started to make time, of course you do. I've started to make time to put some more effort into cloud events because I'll let you down and that's shown on the list, I'm gonna do this, yes. Yes, yeah. So you don't have to wait for next week's call, obviously. If you can put some text out there and if offline over the next couple of days, Slinky looks at it and says, oh, yeah, sure, that satisfies my concern, then I think that gives John a little more faith that it's actually gonna stick around. I'm gonna put more effort into it, sorry. Okay, cool. I always feel super bad in front of 20 people here. Sorry, I certainly didn't mean to do that. No, no, you did, John, and thank you for that, we appreciate it. Okay, let's see moving forward. Okay, I think this one, let's make sure I didn't skip one, yeah, multiple X, okay. So this one's another Slinky one. Would you like to talk to this one, Slinky? Yeah, yeah, I think nobody brought up any concern, or any things that might break because of that. And I think the Linus Linus, I think it's pronunciation. Comment is exactly what I'm trying to say here, which is that we should, yeah, exactly, is that we shouldn't enforce the fact that you can have in filters some kind of side effects, in particular in this kind of declarative filters. So I think we should drop this strong constraint. Okay, and just from my point of view, because I know I was one of the ones who was really worried about this, I tried to think of a concrete example where the order would matter, and I couldn't think of one. It still feels like there should be one, but I just couldn't think of it. So barring that from my point of view, I don't have a blocking concern, but Clemens, you may have had one because I think you spoke up last week as well. Did you have a concrete example where it would fall apart if we remove this must? Since that ends up being, so logically, I think logically there's no change, and it just becomes a local decision of what you want to go and do and what you want to do first. So I'm fine with dropping it. Okay, anybody else want to chime in one way or the other? Okay, any objection to approving then? Cool. Okay, and thank you, Slinky, for giving us one more week to think about it. Appreciate that. So, approved, okay. This one. Okay, so I had a very long outstanding AI to propose a restructure of our directory or our repo. What I was gonna, what I'm proposing is to create this directory structure and then move the appropriate files into the right spots. I wasn't sure whether we wanted to create a bindings and format subdirector in Cloud Events. I don't think my PR actually shows that yet. So for right now, everything aside from extensions and adapters is at the top level of Cloud Events and so at the top level of our current repo, but we can move them later if you guys want to. That's the proposal. Anybody wanna chime in? Yes, no? It feels like this probably will end up being related to whatever I'm proposing for governance and branches and things. And I would ask whether we want to tie the versioning of all of these things together or whether maybe it would make more sense to have a repo for subscriptions and a repo for discovery, et cetera. So if we make the repository, the unit or versioning as it were, I don't know whether that's the right thing to do. I'm just suggesting that we should consider it. Right, and in the past, I think we talked, I think the last time I talked about this was before you really joined the group. I think in the past, whenever we've talked about the possibility of creating separate repos for things like subscription discovery, the general consensus at that time was it's probably not big enough to warrant a separate repo, but maybe things have changed and people's opinions have changed. Does anybody think we should actually create separate repos now or keep it where it is? I think if you look at this discovery and subscriptions kind of tied a bit together, even like, so I don't think that going into several repo we will increase the visibility. I think it's going to be too much spread. I prefer your folder structure, I don't think. But the versioning, I do agree that we could kind of change the versioning, but I'm not a big fan of having like 10 repos to look after to just understand the whole project. But that's my opinion. And that's fine, but do we think that it's reasonable to try to break apart the versioning of the main cloud event spec from subscriptions and discovery specs? I've worked in repos that have the version by branch name because there is one version that covers everything in that repo. And I've worked in repos where tags are used instead because it covers multiple different aspects. I agree with you. I like the fact that it's the versioning, like kind of what you find in JavaScript, we like learn, which is basically multi versioning inside of the one repo. And you think tags are just, I like that idea. So John, let me ask you how that would work in practice though. Let's say we decide to version cloud events like we're doing today, but then we need to version, say subscriptions more often for some reason. What would the GitHub releases look like? Well, how would their numbering scheme look and this is spitballing with only limited knowledge and not having sort of prepared all of this, but I would imagine we could do the releases instead of just being 1.0.0, would be subscriptions dash 1.1.0 or whatever. And that would effectively give the context of the tag slash release, which I generally expect to be a tag that points at a commit that changes the version number within the document, if you see what I mean. So we wouldn't, sorry, go ahead. No, so that implies then, yeah, I think I need to separate it right. Because releases can be whatever, I guess subset of files you want, technically, if you think of it as a bundle, like a zip file, but if we were to create a separate branch, that makes it a little more interesting, doesn't it? Yes, and I've personally found that most of the time you don't really need branches, you just need tags. And then if you need to effectively patch things, then you can patch via creator branch at the given tag. I guess you do need to have a policy of how you do that. So you could have a branch of spec dash 1.0.x and subscriptions dash 1.0.x if you wanted to create branches. In terms of the zip file associated with the release, I wouldn't actually bother trying to limit it. It's more that if you're looking at a tag of spec dash, or maybe just cloud events, 1.2.0, if we ever have such a thing, then hopefully people would be aware that the thing that's being versioned here that's being tagged is the stuff under cloud events and not the subscription stuff. The subscriptions bit could be partway through a different kind of change and you wouldn't particularly look at it. So it's a pin that's only relevant for some subset of the files. Yeah, but then I think you get into what I think Eric is mentioning in the chat, which is do you get into some sort of weird compatibility thing, right? Because if someone jumps into the subscription version 1 branch, they will see the other specifications in that branch because you can't have a branch without doing the entire repo in the branch, right? And so they're gonna look at that version or they may look at that version of the cloud event spec, but that may not be the very latest version of cloud event spec and is that gonna be confusing? And I guess that I would hope that the subscriptions documentation spec, whatever, would say what version of cloud events it depended on like a library dependency. And so if we're partway through doing something with the cloud event spec and it's not really settled yet, that's okay, because the subscription spec says, well, the version you should look at is 100 or 101 or whatever it is. It's possible that we just don't really know how all of this will evolve enough to design a decent versioning system yet. Yeah, could I understand what you're saying conceptually? It's just in practice. I'm not sure how many people will think about, oh, I'm in the description API, I'm in the discovery API spec, therefore rather than just going to look at other files in this directory or in this tree, I need now go look at the readme to see which version and which branch to go look at to see the correspondence to this version of discovery spec. I'm not sure people wanna jump through that many hoops. Like the way I do it is like visiting the readme, I automatically update the readme whenever I do readme so you can see put in the readme something that link to like the latest published version. And then your main, basically your main branch is like the working branch, but the readme is updated every time that you do when you release, and when you do the new release, basically your API is just pushing the tag, modifying the readme, and like with Conventional Publix, you can automatically create a versioning system. I have like an open source project, who does that, that is not completely finished, but I could work on it and apply it to the spec if you wanted to see what it can look like. Right, but the problem that I have is. So like this one. This matrix is gonna get very complicated if everything is in version at the same time. No, it's just that the latest release won't be the same version. The rest will be the same, no? Well, but let's say we have discovery on here and that's at version 0.5, right? If I click on that link right here, that's gonna take me to a particular snapshot of the entire tree, not just discovery, which means that version of cloud events may not be the right one that people should be looking at, because that's a point in time statement. In the meantime, we may have released 102. You're right on that one. And I guess that's where it depends. What does the discovery 0.6 or 0.5 depend on? Does it depend on 101? Does it depend on 102? Or worse, does it depend on 10? We haven't really released this with a number yet. Right. So let me ask this, because I don't wanna rattle too much on this. Do we have to solve the versioning problem at the same time as deciding whether we want a new directory structure in here? I'm inclined to think we don't have to, meaning I think we could do this and then decide, oh, we like John's versioning scheme in the same repo, or we say, no, this is getting too complicated. Nope, we need to split it out. And maybe these become their own repo separate from cloud events. And at that point, we can move everything back up into the top level because now it's just cloud events repo. It seems to me we can almost make a secondary decision later to see how versioning might affect us. But in the short term, it seems to me a grouping of directories would be helpful for people just to find stuff. One gigantic long list of files is kind of annoying. Yeah, the only downside of that is that seeing a history of things is harder if it's moved around. It sort of feels like it shouldn't be. Git should know, oh, this was moved from the top level to under cloud events. And back again, I will treat it as one file for history perspective, but I don't think it shows that way in GitHub. Oh, it doesn't. I thought the history moved with it. I could be wrong. And I'm not sure it's a sufficiently compelling downside. The other downside of doing this without having decided on versioning stuff is it punts the versioning decision and we may forget that we need to think about it. But we'll tell you what, I don't wanna rush this decision. Let me take the AI to go investigate. I really wanna say that the history moves with a file because I don't think GitHub, I'm sorry, I don't think Git treats a move as a delete and a create. I think it treats it as a move and then the history goes with it, but I don't know for sure and I will double check that because that may be part of our decision-making process. Yeah, yeah. Okay, in the meantime, think about this, think about whether you, everybody think about this structure, think about whether you want another so-structure under cloud events and think about whether we should resolve all this at the same time with the versioning stuff. Just to make our life even more exciting. And so John, if you wanna think about what your versioning proposal would look like, that might be useful discussion to think about when this comes back up on the next phone call. That would absolutely be part of what I'm thinking about with the governance change AI that I've got on my plate. And I'm expecting whatever I come up with to be controversial just because versioning always is. Yes, okay, Slinky, you get the last word. Yeah, I just want to say that the discussion whether we present to our users the spec versions, in my opinion, it's not something we should solve in the repository. Like the first time I blended in the cloud events spec repo, I was like, okay, why there's the link to the version and then the link to mass, it doesn't make sense. I will prefer that we solve the solution, we solve this kind of problem at the website level. So in the website, we have proper links to the various releases of the specs and for each subspec, we have the link to the spec or better the spec render the straight inside of the website which shouldn't be hard because it's marked on at the end of the day. So yeah, that's my last thought about that. So I'll make sure I understand what you're saying there. You're suggesting that the links in the documents themselves sort of resolve this problem for us, correct? No, I'm saying that the readme needs to help me navigate through the repo, not through all the spec versions. That's something that the website should do. So when I go to the website, I select what spec version and then I get the list of the all subspecs and I click on a subspec and I see it rendered on the website. So that would then though imply that someone could not do a get clone, do a checkout of a particular branch and see everything that goes together. It can with the tag. So I'm implying the fact that we have tags, okay? But like as I said in the chat, you need branches like for example, 1.2, 1.1, 1.2 branches if you need to do patch releases, okay? So if you need at some point, so if at some point you release 1.2 but then you need to release 1.1.1. In that case, you effectively need like the branches, okay? But I don't think we ever had the need or we will ever need that. So it's a complication to be honest and tags are more than fine, I think. Okay, let's all think about that one. Okay, all right. So we're gonna hold on that one, that's fine. Let's keep moving. Slinky, you are up again. Yeah, open the issue because just looking at the PR doesn't make sense. This issue. Yeah, so basically somebody opened an issue in SDK Java where he made me notice that there is this paragraph in the Kafka spec that is in contrast with the sentence that is later in the same paragraph. So one part of the initial sentences are exactly like any other protocol binding we have, okay? And it claims the usual stuff. So if the content type is present, the value is prefixed with application called blend then it's structured, otherwise it's binary. But then below there is the sentence, if the content type header is not present, then use structured mode with JSON event format. And yeah, of course the two sentences are in contrast. And I propose two different PRs, one excludes the other. So one PR is just that we align with other protocol bindings and we remove the other sentence which is conflicting. Or the order is what I say, the more Kafka-esque approach. So in Kafka, it's not usual to send the content type header. And that's, I think, the reason why there is this, why there is this sentence because it's very often you send just the message encoded and then topics you already know what kind of content type is in the topic. That's awful. Okay, okay. I'm just, let me finish the proposal. So the other proposal states that if there is no content type, so if there is no content type then it's JSON event format but without being in conflict with the first sentence. So these are the two proposals and yeah, pick one. The Kafka thing is a very interesting one because there is a, so Kafka has the schema registry, but it's one particular vendor and that is popular. And what that does is it effectively puts a tag as a pointer into the schema registry, kind of into a magic leading header inside the payload. So instead of using the metadata, they're actually stashing that information into the header of the payload and that then references the outside metadata. The problem with that is that without touching the message you can't tell what's inside of it. Like the only point when you can tell what's inside that message is when you deserialize it. That is okay for the narrow case of having to deserialize it but it's terrible for dispatching. So if you want to round the message that is end-to-end encrypted, for instance, then you can do this based on the criterion of what the content type is because you can see it. But if you have to crack the message body, then you already have to go and engage the serializer and you have to go and probably decrypt it so that becomes more expensive. And that's why that should just be there. Well, don't get me wrong, Clemens, but I'm not saying that one approach is right and the other one is wrong. I'm just saying that this is what Kafka developers are used to do. That's why I propose this approach with the content type. In any case, the spec I think now is wrong and has to be fixed. So one way or the other, but it has to be fixed for sure. Yeah, so Clemens, if I understand all this, the question for us isn't, should people include the content type header? Whether it's good or bad is a different topic. This is, you get a message, content type header is not there. What do we do with it? Do we treat it as binary or structured? Well, yeah, and we have a rule for how those things should be formulated. I mean... Well, what is the rule? Cause it seems, with some misunderstanding, this rule up here says it defaults to binary. Down here, it says it defaults to structured. That seems inconsistent. Wait, it's not present, wait, okay. By the way, this was added by you, Doug. This looks... I am not surprised. Yeah, it was added in some... Yeah, I looked at the git blame. I'm not sure why it was added, to be honest. So... To be honest, since I am not a Kafka person, I may have added it at the same time I added it, so like all the protocols just for consistency and maybe that was wrong. Yeah, that may be. Indicating it to the structured mode. So for Slinky, when you say I added it, do you think I added this or added this or both? No, the second one. The second one, okay. Say that in the comments. I think that second one is incorrect. Okay. So you would agree them with this PR that just removes this? Yes. Okay, and this PR... I wonder how we get there, because there is a... The HTTP case. With the HTTP case, it's clear that, yes, so we need to have the content type to identify structured mode. And then if you leave that off, then it's implied to be... If nothing else is there, it's application octet stream. And then it's effectively binary mode, if you will. Yeah, so that sentence is a conflict. So you added that. Apparently, I'm just slinking. But apparently we all said yes. Yes, I blame you Clemens, ultimately, for everything, so. Because we have collective idiots. Yes, okay. So other people want to chime in between having these two conflicting statements. The proposal is to remove this one. What other people think? Any objection to heading that direction? Okay, so hold on a second here. Why is this not telling me what branch she did? Oh, there it is, there's the branch. So it seems to me this may be a candidate for a 101 hot fix. Is that true? Because I mean, it seems pretty bad if we have conflicting statements in 101, right? Yes, yes, yes. Okay, Slinky, would you agree? Yeah, I can backport it. Or you can do that. If you want, I can do it. Yeah, if you can do that, that'd be great. So first things first, any disagreement with approving this change? Okay, cool. In that case... Let's reject the other one. Okay, hold on. Slinky, open KR4V101. And you want me to reject this one, right? Yeah. Okay, so this is 813 closing in... Flavor of 813. Okay, cool. All right, thank you all. The techniques were out of time. Let's just do a quick check. I think I got everybody. I miss anybody for the attendee list. All right, cool. In that case, we are done. If you're interested in the interop call, hang on the line. And just a reminder, we will not have a meeting next week due to coupon. So we'll meet again officially in two weeks. Okay, cool. Thank you, everybody. And again, stay on the line if you wanted to talk about interop. Thank you. In the meantime, I want to see what we do for HGP. I want to talk about interop. I just don't know what to have to tell you. Well, I think it's going to be a very quick call, so... Yes. Yeah, you have some stuff to say. For once. For once, I like that. So, Conan's, I'm looking, I'm not sure the HGP spec actually has that sentence. So I'm just completely missing it. It talks about what to do if the content type header is there, but it doesn't say what to do if it's not there. Let me just double check here. Because that is technically illegal. Okay. No, you don't have to have the content type header on HGP. I think you must. Mm-hmm. I don't think so. Maybe I'm looking at the wrong spec. Let's see, 72.30. Hold on, let's pick another format. Oh, is that in 31? This is one of those weird headers which is like reference in 30, but then it's probably defined in 31. Why would I have added that to the Kafka? I don't know Kafka well enough, so why the heck would I be the one that adds that? I didn't know. Content type. Okay, no, this was added by Slinky. He's trying to shift the blame to me. Hold on a minute. According to blame, this exact sentence was added by Slinky two months ago in 727. I like he's shifting the blame here. So funny. Where is the sentence? See, in HGP, so HGP, as I said, if a content type header is not present, the recipient may either assume a media type of application, octet stream, as you heard that earlier, or examine the data to determine its type. So it's not required, but it's implied that it's a binary then. Okay, okay, no, I apologize. This was added, holy crap, two years ago by me, or at least that was the latest update before him, hold on. Maybe back then you knew about Kafka. I would never claim that. Hold on, I don't know, try clarifying Kafka. I must have done this on behalf of the group or something like that. I cannot imagine I would make these kind of changes on my own. That's an excuse then. Well, because I, like I said, I do not know Kafka and I'm looking at the changes here and, okay. Okay, so it's been there a very long time. Anyway, it's not in the other specs. I guess we don't need to, well, do we need to worry about clarifying text for the other specs like HGP? Do we need to add something that says if the content type header is not there, what to do? Because as you said coming to kind of implies binary, right? Yeah. Okay, I'll tell you what, I'll take an AI to add that to a future agenda topic. Hold on. If the content type is not one of our well-known content types that we define for our structured nodes and it's automatically binary. And then whatever, and the content type that we find there or that's implied is then that of the body. Right. Okay. So let's get back to the meeting at hand, discovery. All right, Remi, you said you had something you want to talk about. Yes. So I did work a bit for once. I'm able to connect to your systems. I cannot share, sorry. Do you want to share? I can stop. Yeah, I'll share. Okay, there we go. It's not like crazy new things, but at least it's some progress. So basically now I see your system. I can see the ping service, but I need to implement because your subscription is basically, if I don't provide you with an interval for the ping, I guess it doesn't send any ping. So I need to do the subscription configuration system in terms of UI. Oh, okay. And one thing that's what I was telling you yesterday is in fact, depending, in my opinion, if I look to like the spec of cloud events, always with the, okay, it's not this one. The, within mind the gateway, what I'm seeing here is like, we send back some services with a subscription URL and subscription config, but as soon as I put the kind of, so a gateway in the middle, basically, I have a chance that I have to overwrite all the subscription URL, a subscription configuration, and potentially the subscription directs. By the way, there is a typo, you know, subscription direct. You're right, it gets wrong. I was like, maybe it's option. No, no, okay, it's just a typo. But so the thing is this will be overwritten because if I act as a gateway, I have to be the middleman. So I'll probably, I can even have like a shift of network. So that means every service that I start to proxy, I need to rewrite their own definition to remove the subscription and put my own subscription in place basically. And that's why for me, it was a bit, I was thinking of even when you call the slash services to have like a subscription group that includes services. And then like that basically is a subscription system that can be overwritten without changing the service. What I do not like there is when you act as a gateway, you take the service description that is written by the original service and you start changing the definition to inject your own subscription in it. And I had like tissue with that. So I'm pretty sure I'm not explaining correctly what I'm saying. So I'm not sure if you follow what I wanna say there, but I can work on a PR on that, but it's more like, when you act as a gateway like the middleman, in my opinion, you should not have to temper with a service definition. You could take the service definition or by the way, you can subscribe through me with that type of subscription. And then you keep the original service definition as it was written by like the true service. And it's just a subscription parameters that are different from the original. Because I really think like in, yeah, I need to write more. Yeah, sorry. It's just because I was working on it yesterday night and try to explain, but when you have like, if it's an internal service that is exposed to your customer through a gateway, at one point they won't be able to reach your internal service. So they won't be able to use your original subscription system. They have to go through a second subscription system. So can you show your screen again? I got a question for you. I think I understand why you would need to modify the subscription URL. So it points basically to your gateway instead. But can you elaborate on why you think you need to change the config and the dialects? Well, because for me in the config, I can think of like, let's say you need to put your customer GWT token or something basically kind of a security related. And that can be additional to the original one. You can also define that if it's an external, there is some default parameters that you can even remove some subscription configs saying, okay, like in my case, like this one will always be this. And like, you know, those break or authentication or that I can see that I would have put there by default. But would those be with the authentication thing that you just mentioned? Would that be something that would be to be used by the subscription manager when he's sending the event? Or is that a parameter that needs to be on the subscription create request itself? For me, it's just on the subscription create itself. Right, in that case, I don't think you want to modify the config because that config is meant to configure the entity sending the events or generating the events, right? So you want to add a header to the subscribe operation itself. And I'm wondering whether that's more of a protocol thing down below. So that's the way you see the subscription config because for me, whether I had trouble when I looked at yours is like, the way I was thinking is probably reverse of what you think. Because for me, my pink service, so I also have a pink service. And basically the pink service is emitting every five seconds because that's just the way the service is configured. So me as like a service provider, I'm just saying, this is it. Because if I have like five different subscriptions that ask me different interval, then in fact, I have to start like fourth thread. And basically I can have like a denial of service if I start having like millions of people who just on purpose ask for different interval. And while, let's say if I'm detailed, how do you see the subscription config? Is it gonna be your repository? Well, I think in a GitHub case, I think you can go either way, right? You could say that the specification of the repository could be in the URL to which you send the subscribe or it could be as part of the subscription config. It depends on how GitHub chooses to define the operation. Because like this one, if I subscribe, I have a new burger under the description, right? But it will, I'm not in charge of how often the thing is, so I cannot interfere with the service just with a cloud event subscription. Just for me, the services can be a complete app. So it's not like me as a subscriber who can define the configuration of it like if I take Salesforce or things like that, I would expect to get some events but not to be able to kind of config Salesforce through the subscription config. I'm not sure I'm following. Yeah, I do understand. But I think we need to clearly differentiate whether you're talking about being able to say that you need additional things on the subscribe request and that's separate from things that the event producer will need in order to either generate or send the event. So those are two very different things. So like, okay, my case, I'll try to explain it from where I start is I'm here and I'm like, okay, do guys like two services and I'd like to subscribe to one. If I just subscribe, when I subscribe, I need to give you the interval I want and there's a second parameter, it's a string I forgot what it is. Probably the content of the event. So as a, when I do that, that means when I click on subscribe, I need to pop up like a form to ask the user like what parameters do you want to ask? That means also I can have like as many subscription as I want on the same service because I can re-subscribe with different parameters and continue like that. I'm just kind of thinking out loud. I'm sorry, maybe there's no question, but that's the way I saw that. Why the, my thinking was more, it's already established applications so they already have their own behaviors and what like GitHub in my opinion already have is on a behavior or if I do my own application and they will start emitting events without me being able to choose. Because in a way, when I, sorry, I'm not sure. When I subscribe to your pink service, that means a subscription configuration is basically telling your pink service when it should emit an event. While for me, like a subscription has nothing related to the business logic of when my service should emit even because that's like business logic. So that's the own application logic. Correct, right. And there are definitely gonna be some services that fall into either category, right? There will be some that you don't get to necessarily choose anything, right? It's just, you're just connecting up to the stream of events, but then there will be others where it says, no, you can tell me more information about how you want these events to be generated or when they're generated or something like that. Yeah. I'm not quite sure what you're looking for. So that's why I think our two vision is a bit different. And that's why for me, the J-Wade, like DWT token will be in the subscription config because that means, yeah, I'm that customer. I can't subscribe. This is my proof. And so it will let you in or out, depending on the subscription config. So that's why I was saying it's there. Oh, okay. So hold on. Okay, hold on. Let me take a look. So I think what you're saying is you were viewing subscription config as configurations for subscribing. And I believe the current spec is the other way around. It's subscription config isn't for configurations for subscribing per se, as much as it's how to configure the event producer itself when it generates or sends or at least when it generates the events. I think what you're saying is we need some place to be very clear to says, hey, if I need additional parameters on the subscribe itself, this is not going to influence how the events are generated or how they're sent. It's just, you need additional information for me to let me even do the subscribe. Where does that go? Yeah, and that's the way I interpreted it. So probably wrongly, but yeah, that's a good point. Yeah, that's a good point. I'm not sure where that would go. Maybe it does go there. I don't know. Maybe I'm wrong. We need to talk about this. That's a good question. I don't know. Ah, cool. So that means I was able to explain a little bit correctly. But yeah, because for me, I don't see why the subscription will interfere with the business logic. So that's why, even if I understand the argument on the pink service, to be honest. So it's another view that is possible. But I think most of the case should be like, I already have running services. I have running application. I'd already stream lots of events. So it's not because you subscribe in a certain way that I'm going to change my old infrastructure for you. So that's why I was more seeing it like, as just a subscription on it as like, tell me who you are, what is your authorization. That's an, can you give me a favor? Cause I think this is a, this is a great discussion that we need to have with the entire group. And just open up an issue and says, Hey, where do I put configuration options for the subscribe call itself? Cause I think that'd be a great discussion point. Cause maybe subscription can take is for both. I don't know. That's a good question. We need to talk about that. Yeah. So I'm happy because it's a little bit more concrete. Like, I think we've like the UI, I fixed a few more things, but we're making progress. And that's also why I'm not super vocal in the filtering parts. Because for now, I just want to have like the full, like the infrastructure working and interoperability working well before I even think about filtering events. For now. Yeah. Okay. Yeah. No, it's a good discussion point because I think I agree with you. The spec is not clear today where that information would go if anywhere. Okay. Okay. Thank you. Anybody else have a topic to bring up? And Clemens, I saw your Slack message. I just happened a chance to click on your link to see what it's actually points to, but I'll get to it later today. Oh, you're going to share. You're on mute Clemens if you're talking. No, you can hear me. I built an Azure function that is proxy the Azure Resource Manager layer is also proxying Event Grid. So this is a little unwieldy to look at. So I think I just pasted that in here. So what it does is it basically creates a discovery documents that has effectively every service that sits in an Azure resource group. So there's a storage service and there's a function app itself, but I'm going to put some more there. So there was an effect that this is the Blob Store, I think it's a storage account. And so that has all the events. So I'm removering all the events. I'm just pointing, I'm also pointing to the respective schemas even though there's some detail missing here. And then I have a source template how you actually go and define this. And that's a little wishy-washy I need to go in and see. We have to find the source template thing, but the mapping of the data, like the parameters is a little, like that's a clear me at this point how we're going to make this work. So that's effectively our storage account. And then we have here a server farm. So that's the app service and all the various operations that it can raise. So this is all just live and what we raise in Azure. So I haven't done any translation work. This is original. And then what I'll do, so these are effectively three resources which live inside of this resource group in Azure. And if you subscribe, you will be doing this through these subscription links. We need to add a little bit of extra data here. And then I'm affected taking our subscriptions API that we have here and proxy that off to Event Grid so that you will be able to effectively interact with those Azure resources using our APIs. Cool. That's exciting that it's real. That is super real. So I'll also have the, I'll have some resources which will go and do some automatic raising of events. They will go and something we're going to throw something into the Blob Store and then that will raise the event. So these will just be real resources. And with this app, I'm going to give access effectively into those resources without requiring, I mean, I'm making a little hole into Azure if you will so that you can go and subscribe to those events without requiring authorization. Cool. That'd be neat. I like it. So that is mostly done, but I have to go and patch up some holes and make it more approachable. Like it should be able to get the, like this subscription URLs that I have here should be more straightforward. It might be some information missing. There's also some, like as I'm filling out all the metadata, there's some stuff that looks fairly repetitive and not yet sure whether I like that repetitiveness. Like you have, I have four times the same URL and I need to think about whether that's the same thing or whether we can probably go and consolidate the metadata a little bit more. Yeah. Good thing to discuss. Yep. So in two weeks when we meet again, officially then there will be certainly more and this will be more rounded. Cool. Also for everybody to go and take a look at, if you guys want to peek, I have this in a repo. So it's not that I'm doing this in private, I'm actually doing this very much in the open. So I pasted it in the chat window if you want to feel it. Don't expect docs or anything. So in source and there's some, this is a client. The client is actually, it's kind of fun because it's using the Azure Relay. So it's creating a little, it's creating a little, if you scroll down a little bit further, it goes and creates this start event listener thing is actually creates a hybrid connection listener. So it creates an HTTP listener to execute on your local machine and that has an endpoint in Azure and that where effectively the HTTP request comes down to your local death machine. And so you can go and subscribe from the Azure service into that endpoint and the Azure service will call them the public HTTP endpoint, but the public HTTP endpoint will end up on your own local box. That's like NROC, but we have that too. So I'm using that for my own purposes here. Are you familiar with that with NROC, Doug? I'm sorry, I'm a mute. No, I'm not familiar with that, unfortunately. So it's effectively creating, it's a web socket based delegation of listening to connections and then those connections are being proxied to your own machine. So it feels and looks like if you're listening on your local machine, but the DNS and the actual endpoint is provided in the cloud. That's cool. But the HTTP requests come to you. That's really cool. Yeah. Basically it's just whatever we've asked you to know. It's the Azure Reload service. So I'm just using that for my demo here to just a playlist so that you can actually go and debug when the events are being raised, et cetera, that all just comes to you without you having to futz on the server. And then you can be behind Nats and firewalls and it just works. And then the other project, so this is the client and then you go back, there's actually the server in source. There's the other project. So that's the Event Grid project. And there's a bunch of JSON files which I stole from the, I had to go and steal those from some other place in Azure because I don't have access to these types but these are all the event types that are being thrown to Event Grid. So they are just there. And there's, the subscription service is implemented there and the discovery services implement there. So that's a subscription service that's basically proxying if you will the Event Grid service then. Oh. Clemens, I was also looking at the schema registry spec because I'm thinking of just like putting something online already that looks a bit like NPL to be able to publish publicly. The service registry in Event Hubs? I don't know. Maybe it exists already. That's why I'm talking to you. We have in Event Hubs, we have a service registry as a preview that is a version of, that influence I think the zero point wave version of our schema registry. Because when I look at the schema registry, one issue I got was like, there is no group. It was done. So our schema registry that we, so the schema registry that we implemented for the Azure Event Grid has schema groups. It's literally the initial spec that we submitted into this effort is the same schema that we used for our preview. Okay. It's great. I think the fact that it's attached to Azure might, I mean, shoot for some people, but... Well, I mean, the point of doing this is that everybody can implement this, right? So I mean, the schema registry implementation is actually fairly easy because you only need to have a file store on the bottom. Yeah, yeah, it's super easy. Like you just need like, so I have like a serverless framework that I did so I can use it on AWS because it's also on Azure, we function and then you just start like a no SQL you can even use a like a Blobstore if you don't want to do any search. And that's about it. Then it's just a few, and like plugging probably get a authentication to authenticate who publish the registry but that's about it. I think it can be super useful. So yeah, cause maybe thinking of looking into it and do like a small project for that. I think it's useful. But now that I see that you already have something maybe we should just say, okay, use that. Yeah, so one of the things that we have clients which are talking to that schema registry that we have and we have them for all the SDK languages that we have. So that meant in Java and JavaScript Python. And we, so those clients will work against whatever open API specification we end up with. Okay, so maybe I should still do something so this way people can have their own if they want or use like a generic one. Yeah, I'll see. I'll look into it. Thank you very much for all the information. You're welcome. Okay, cool. Anything else people want to talk about? All right, in that case, it's lunchtime for me. Happy lunch. Yay. All right, bitchy. Okay, talk to you guys or see you guys in two weeks. Bye. Bye. Oh, and Clemens, don't forget this to register for the two events already registered. Yeah, all right, cool. All right, talk to you guys later. Bye.