Hello, Daxes, Matthias. Hello, how's it going? Hello. Good. That was slinky. Yeah, for once that I did something. We may have a, go ahead. No. Talk to you later. Okay. Yeah, we may have a very small call today because the vacations in the US. Hey, Timmer. Good, good. Hello, Heinz. Hello. Good to hear from you guys again. It's been a while for you. Yeah. Well, between vacations and those nasty clients, I got a little side track, but I'm back. Those darn paying customers, man. I tell you, life would be so good if it wasn't for stinking users. Hey, Tommy. Oh, hey, Mark. How's it going? Doing great. That's good. Hey, all of the tomorrow. Yeah. You'll be nice to, you know, have that extra time to stay at home. More dad humor. I like it. It's funny. I'm seeing that phrase dad humor more and more. And I'm trying to figure out whether we should be offended by this or not. You're making fun of us. Yeah. Hey, Christoph. Hey. Hey, Scott Gustavo. Oh, no. Christian, are you there? Hey, good morning. Hello. And Colin. Good morning. Hello. Ryan, are you there? Yes. Good morning. Hello, Jim. Hello. Did you get any feedback from your question about setting up a meeting for the protobuf stuff? Negative.  Hey, Eric. Okay. One more minute. I'll get started. Say what? I don't know what it's going to start now. Maybe make a very quick call. Okay. Anything from the community people want to bring up? That's not on the agenda. Okay. Um, STK call. We'll have one right after this one. I don't think we talked about anything too important last week other than. Some of the PRs around governance and stuff like that. I think there may have been some minor changes made since then. Is there anybody from the STK. Sub team. They can think of anything worth mentioning. Okay. I don't know if you would like the discovery integration or not. Or creating a side one. Maybe it's not for this colleague. Yeah, that's a good topic. So, um, Let's put that down here. I think that's a good topic for this phone call, not just the STK call. Okay. Yeah. Cool. Okay. Um, in that case, moving forward, uh, Tim, or anything you want to bring us up to date, we're going to move on to the workflow stuff. Hey guys. Yeah. I mean, uh, the last two weeks, sorry, I missed last week's meeting. Uh, we've been working on SDK. So we added the go SDK. And there is a PR for a Java SDK. So those two, uh, that's what we've been mainly doing. And yeah, those are the main things. Cool. That's exciting. Any questions? Yeah. I mean, also another thing I wanted to just mention, I just wanted to make sure that you guys are interested or could help us with, if you guys have any experience with Kubernetes, uh, custom resource definitions, we've added those in, uh, just to kind of, uh, edit the go type so you can create your CRDs. Uh, that are spec based types that are based on our workflow definitions, but we're kind of looking just, you know, for help from individuals to know this stuff better, because they're kind of experts on that. But if anybody on this team also knows this stuff pretty well, it would be really nice to have your opinion and have you look at it. Sorry, I talked too much, but yeah. No, I know there are some people on the call who have a lot of experience with CRDs, but I don't want to call them out unless they don't want to do it. So, uh, anybody want to volunteer to speak up? Okay. Um, this is Vinay here. Yeah, Vinay. I can. I'm happy to where exactly is this, uh, uh, is there like a, is it in the spec or is it in? Yeah, I'll link, I'll link in the chat just for in a second and then you have time. Yeah. Thank you so much. Just an overview. Sure thing. And somebody's smiling in the chat room. So take that for whatever you want. Okay. Before we jump into PRs, anything else that I forgot to add that people think we should talk about? Alrighty. In that case, let's jump on to this one. See who was this. So this was Lance. If I remember correctly, I don't see him on the call. If I remember correctly, this one was more of a copy of the general guidelines that he had written up for the JavaScript SDK, I believe. And he just wanted to put this out there as a proposal for SDKs, for the other SDKs to possibly pick up. I don't think it requires them to pick it up. I think it's just sort of general guidelines that are good. They're looking for a sort of like a rough draft starting point for their own SDK work. Um, but I thought because this is going to land in the cloud events repo itself and not an SDK repo. I felt like it was from a process perspective, it had to get bumped up to us to, to take a quick look at it. And everybody here a chance to review it. So even though he's not on the call, are there any questions about this one? Any of the SDK folks have any issues with this? Jim, your hands up. I'm just wondering how much of this is specific to SDKs and how much of it can be applied to the.  I don't think it's necessarily SDK specific, but I'm not sure it necessarily applies to our process because the way we deal with PR is very different, right? We don't follow a normal code PR style thing, right? We only do things on Thursdays and stuff like that. So it's, I'm not quite sure it applies to us from that perspective. So this is more just setting expectations from, you know, trusted committers and stuff like that. Yeah, that kind of stuff. Yeah. You know, how do you label your commit messages or how you label your PRs and stuff like that is just things that I think are more important for PR processes where you're merging PRs on a daily basis kind of stuff. Okay. Yeah. Okay. Okay. Any other questions, comments? Any objections then to approving that one? All right. Done. Thank you, everybody. All right. Well, hold on. I hit the wrong key. All right. Next one. I think Francesco, this one might be yours. So you get to actually describe this one if you would. So this one is a next-gen item that I took two weeks, three weeks ago. And it basically, it's basically a draft. That talks about a management community management of the SDK projects. In particular, it goes through the problem of security patches, ensuring the project out even when the maintainers are not available. And how we want to end those corner case situations like an endover of a project to a new maintainer where the previous maintainers are not available anymore. And the other corner case is when the community wants to archive a project. And at the end of the document, there is a section that explains a voting process for this corner case situations and for changing the document itself. I also decided to don't go through the new maintainer discussion, because it deserves a separate PR, in my opinion. Okay. Any questions or comments? And so keep in mind this process is just for the SDKs, but we thought it would be important to have sort of an overarching process for how to manage the SDKs themselves. Since we're a little bit loosey-goosey on that. I have a question. Is this, I like the, I love the idea, but also is this process of determining if the liveliness of the project in line with other projects that have been out there? I'm just curious. Francesco, did you want to take that one? Okay. Can you repeat, please? I guess the question is, is the process that you have outlined here, I don't think we need to reinvent the wheel. So I'm just curious how do other very popular open source projects determine liveliness and is it similar? So vote, I took the voting process actually from another community, I'm part of. While for the others, I basically took inspiration from the discussion we had during the SDK meetings. Nothing less. The voting process that I proposed is a voting process that I use in another community. Thank you. Any other questions? Concerns? And keep in mind, if there is something in here that we find just doesn't quite work right, we obviously can change it later on. We'll learn as we go. With the voting process. Yes, with the voting process, yes. Exactly, yes. That way to use it. Yeah. All right. Any objection then to approving? I'm not hearing anybody raise their hands or see to be raise their hands. All right. No objection. Thank you, Francesco, for doing that. Appreciate it. All right. Schema registry. I can't remember. Open this one. Thomas. Let's see. Thomas on the call. Let me see if I can refresh my memory. Oh, so this is a minor one. Does anybody know, I think this is open API. He, according to the editor or checker or something like that, he was using, it was complaining about missing quotes. Now I did see examples where it showed both ways with and without the quotes. But does anybody have any reason to believe that adding quotes would be a bad thing? I just want to give everybody a chance to speak up if they have any opinion on this one, Francesco. It should be the same for every YAML parser. I think. Meaning quotes are okay or quotes are not. Yeah, quotes are okay. Okay. Okay. Some might try to interpret that as a flow. Oh yeah, that's true. That's true. Yeah. Yeah. Yeah. Okay. All right. In that case, any objection to approving that one? Perfect. Thank you, everybody. All right. Yeah, go ahead. Okay. I need to document myself. Yeah. Okay. This one. Oh. Somebody, a camera who was. I guess Andreas. He had some comments about. About the primer. And the actions that we were the. The types in there. He was bothered by the fact that some of these things were in. We didn't, we're not in past tense. In our adapters. And. The adapters are not formal specifications. So they are allowed to change at any time. And I thought that. One is the couch DB one should probably change to be past tense. I thought that seemed to make a whole lot of sense. Cause when I looked at all the other. Types that we had for the other adapters, like GitHub and the other ones in there, they all were in the past tense as well. So I thought following that pattern made a whole lot of sense. But then the other thing I did here is actually updated our examples from fake. GitHub things to actually line up with our rec recommended adapter. Types for GitHub. So that's all these other ones were. They were all in the past tense. And then I made this one past tense as well. So these are just simple typos kind of things in my opinion. The way that it might be questionable is whether anybody has an objection to changing the couch DB adapter. To be past tense for the verbs that we have in there. I think they should be past tense. Otherwise they come across as instructions, not event. That's exactly his argument as well. Yes. Which is why it made sense to me. Okay. Any other questions or comments on this one? Any objection to approving them? Okay. We should all sit in. I said go for it. Okay, cool. This also be non-normative anyway. So shouldn't that be controversial? All right. Now on this one. I can't remember why this popped up in a conversation, but I think it popped up in the SDK call. Someone noticed that we didn't have any code of conduct and we didn't have a code of conduct. We didn't have a code of conduct. We didn't have the governance docs in the SDKs. Then we realized what we don't actually have one for the main project itself. Oh, I remember why this came up. I think. I think as the workflow. I was going through sandbox project that they didn't have a code of conducts. And that's when we realized we didn't have it for our stuff over here. So it thought, okay. Since every CNCF project is actually supposed to. Have a COC and we didn't. We should probably do that to get ourselves aligned. We should have a code of conduct document from. The CNCF project itself. And that's all it has done here. And I just changed. I don't think I really changed anything. Actually, wait a minute. What am I doing here? Contributing. Oh. Wait a minute. I'm sorry. What I did was I added a pointer to the code of conduct from the CNCF thing. I didn't actually copy it in here. But then at the same time.  I just thought this whole section about our meeting times was just kind of ugly. So I just reformatted that and nothing changed. Really there. But then what I did is I moved. Some of our documents like our governance doc into our community directory. This was sort of my attempt at a first phase of cleaning up our directory structure. We had my opinion, or we have in my opinion, way too many things at the top level. So I wanted to push as many things as possible into sub directories. And I thought I'd start with the governance doc while I was messing around with this stuff anyway. So I moved the governance doc into community. And I did some cleanup. And then when I was changing the links, I had to reformat this because this went over 80 characters. Most of this was reformatting mainly because of either cleanup or because things moved in the governance directory or community directory. And I removed the coming soon here because we already have a demo's file. So the words coming soon made no sense. Anyway, the biggest thing here was a pointer to where's our governance doc. This section right here, this is the biggest thing. This information, we adhere to the CNCS code of conduct document. And we just points directly to that. That's about it. I don't know. Any questions on this? Any concerns? Any objection? Okay, what I'm probably going to do based upon what I think I grew to last week on the SDK call was I'll then open up PRs in each of the SDKs to point to something, either our governance doc or to the CNCF COC, but either way each SDK needs a COC as well. So I'll open up PRs in each of the individual SDKs to talk about those or to add references to something. All right, moving forward. Now these issues, I'm sorry, these PRs are too new for us to approve. But I wanted to give an opportunity for any of the authors of these to talk about them if they wanted to. Yeah, I would like for the implementation. It is useful to be sure that I'm not misleading. Well, that's about this stuff down here, right? Yeah, it's just because. Yes, let's hold on on that. I want to talk just about these first. That's fine. It was like the second ones that way I was seeing that. Yeah. Okay. Well, so first, Jim, did you want to talk about yours? I think this is yours. Do you want to talk about this one at all? Sure. I need it. So somebody opened an issue. Because the, the Jason schema definition didn't seem to be. Following the spirit of the. Jason format specification. So the way the scheme or the rigid been defined was the, the data def object could be. Well, dated F could be either an object or a string. But if you read the format spec, it says that data could be about any valid Jason object. So, I basically extended it the type, you know, possible types just to cover all the types that, that Jason supports. So it means that dated F can in this case, just be the word null or be true or, or an array or the value 56 or 42, whichever is your favorite number. Okay. Okay. Too soon to approve this, but are there any high level questions or comments on this? Okay. Please can you get a chance to take a look at that? Make sure Jim did not go off the deep end. And Remy, I believe you wanted to quickly talk about this one. Yeah. Just while doing the implementation. It's just, I suppose it was typo because it's an array. It's a map. So I just changed this. But I wanted to make sure that it was not a misunderstanding from my side. Yeah. No, I think I just goofed when I wrote this up. I think I think you're right. I think it does make more sense as a map as opposed to an array. Yeah. At least with that structure. Yeah. Whole bunch of reasons. Yes. Okay. As long as we are fine. Yep. Okay. Any questions on this one? Too soon to approve. Any questions? All right. Where's my cursor? Okay. This one. I came up with this one. Grants. Okay. This one's interesting. So grant notice that in our spec. We talk about how there's binary and structured mode. And. In particular. Where is it? Somewhere in here. Maybe it's not right here, but somewhere in our spec airs. There's language that implies there's only two. But then the HTTP spec goes off and defines other ones in particular batched. So he thought we needed to add additional texture to make it clear that other protocol bindings may be defined. Okay. I think that was the motivation behind it. And I see. Christoph. You had a question. Yeah. Yeah. I also left a bigger comment on the PR itself. And on the issue itself. I agree. It is very confusing. And I try to explain it. In the issue. But I think I failed. But I think that was the motivation behind it. And I see. Christoph, you had a. Some comment here or additional change. Anybody want to speak to this one? Have any concerns or comments? Yeah. I also left the bigger comment on the PR itself. And on the issue itself. I agree. It is very confusing. But I think I failed at explaining it. Explaining it properly. So I think what the HGP spec defines is another mode, but it's not a message mode. So for the message, you can have a binary or a structured mode. And the batch thing is also a structured mode. Because the definition fits. So in the batch modes, the event is fully encoded using a standalone event format and stored in the message body. That is actually true for the batch mode. So I think what is really confusing here is if you look at the binary modes, the binary mode is. Then the binary mode, the message body is. Exactly the same as the request or response body that we sent. What if you look at, for example, batch, this is not the case. And if you look at other events, formats like, I don't know, the Azure event grids pops up, whatever, then this is actually not the case. So we have the event format, which defines I'm taking the event and I'm transforming it into a message. And then the protocol binding comes and says, okay, here's how you put this message into the transport and then add additional stuff for the request or response body. And if we have, if you see it as a two step process, then the message mode only applies for the first step. And then the, for example, batching only applies for the second step. I'm not sure if I know lost everybody or not. Do you think it's fair to, do you think it's fair to say that there are two modes binary and structured, but maybe they're different flavors of structured. And that's basically what I try to say with my suggestion there. So you may have a protocol binding that has multiple structured modes. So if you, you could have one that doesn't batch and you could have one that batches, then you have two structured modes defined, which we actually do in the HTTP binding. Right. Okay, so this is, I think it's more a question of just finding the right wording, not necessarily introducing other modes, but finding the right wording to imply that, that one structured mode that we defined is not the only one that can be defined. Is that correct? Yeah. Yeah, let's say so. Okay. I think that makes sense. Anybody else want to chime in here? Okay. So let's take, I'm sorry. Go ahead, Ryan. Yeah. Sorry, Doug. I think the, the point you brought up about just the, the, the watch goal message being separate from how it is transmitted in a given protocols is interesting. That's, that's one thing I've struggled with. Just looking at the spec and mapping it to different transports is the message is the same. And, you know, some transports don't have mid data layer and only have a message layer, but how the data is actually encoded. Irregardless of that can sometimes depend on the specific protocol. So I think that's an interesting thought there. Scott. I'm not sure the motivation for this change, but I kind of assume that it's related to pubs of push over HTTP. We'd like to carry a cloud event, but they have no control over additional headers and the shape of the request is, is that, is the attempt to include HTTP for pub sub encoding so that we can decode a cloud event as, as a pub sub push format. I personally can answer that one.  I could be that it's, he didn't specify it. I think the shape of that request doesn't match up with what cloud events defines. And there's no way to add custom headers. So the only way to actually understand if it's a cloud event is to attempt to unpack it first. And it's complicated. I mean, okay, I don't know the details of it, but it sounds like it's simply not the HTTP spec. It follows, but it may be. If you do an own pop subs specification, then you can still use the JSON event format. It's over HTTP. So the, the only thing that play at that mode is HTTP. Okay. Yeah. Scott, you may want to take a look at his original issue because I came up for sure, but I had this vague recollection that when I first read it, I think he was just more bothered by the fact that the spec only talks about two things. And he thought there were three things. Meaning there are two modes. And then the HTTP spec goes off and defines another one. So I think he was just having a mental problem with the spec saying there's two of something. And then we immediately go off and define a third one. And he thought that was just inconsistent. At least I thought that's what he was really focused on. I don't think it actually impacts any of his coding that he's doing, but it could be wrong. Okay. But take a look at the original issue and see, maybe I might be remembering incorrectly. Anyway, we don't, you know, this one's too soon to approve here anyway. But if there are other questions, you know, please raise it in either the PR or the original issue and maybe we can get grant on the next week's call to talk to it again, or talk to it if he doesn't answer it through the issue. Okay. Anything else on this one people want to talk about? All righty. Jim, I assume you don't want to talk about your proto buff, right? No. No. Okay. Okay. And Francesco, you don't want to talk about these two yet, right? No. No. Okay. All right. So let's talk about implementation of the discovery specs. So Remy, you had a topic here. That you wanted to bring up. So let's see. What was it? SDK. I think it was, it was a JavaScript. JavaScript. So yeah, basically when I was implementing it, at first we were thinking of doing a separate SDK. And then I realized like, first, that definition of new types might be useful. Even if the normal SDK just having the interface of what is a service, what is a type. Sorry, my daughter is playing in the background. And then I was like, when I will, when I developed new services, I just like basically by importing the cloud event SDK was thinking it would be nice to just have like the discovery feature included in that SDK because then I don't have to add several layers of SDKs. So that's why I did integrated in that one. I can split it again, but it made more sense to me at that time. And also because like I needed the definition, of course, of the primary SDK. So that's why I did it this way, but I'm really open to respect. And also I tried to minimize the impact. So when you look, there's not the, like there is no dependency to express even if I include express. To make it run. I can demo if you want to demo. I didn't really prepare, but I can do that during the SDK. If you want, but basically the full discovery API is working with the filtering and all those. So in the sample, you see how I see the user of it. You can go to that. Have I lost everyone? No, we're here. Sorry. I'm not used to those huge silence. Sometimes this group is really, really quiet.  So you define your different services.  And then to, to make it serve, you just do the discovery service express. If you have running an express up on your desk to serve the full API. And another question that I raised while implementing is in the spec, we say that the permission needs to be applied on each entity. And if you go back up a bit, yeah. So here in the type, that means basically I apply permission both on the service but when the service and serve with different types of events, I also apply permission on that array of types to allow you to basically like to basically filter those as well. So it will send you the, like the cat service. If you only have permission for widget create, you will display the cat service. We have only the event. We just create and remove all the events that you should not see. Which I guess was the intent of the of the specification, but I wanted to be sure. Francesca, your hands up. Yeah, so I have a question as a new above the discovery spec. I went through it, and nothing more than that. So first of all, your implementation is both client side and server side. Or it's just one of the two. It's just one of the two. It's just a server side. Basically it's just to serve to like client. What is available. Okay. Now my second question is does the discovery spec hardly see hardly depends on the cloud event entity. So I would say no, because at the end I had to define the cloud event type and the cloud event service, which are really close to what exists in the SDK, but they are not directly like they're related from it. Maybe I did the wrong question. What I mean is to, to implement the discovery service, to implement the discovery spec, do you need the cloud event entity? No, no, I don't think that the thing is when you look at all the definitions, some of them are kind of overlapped. So my general thinking is maybe at one point you could basically have common definition. Like you should look. Some example when you define like the schema, the definition of a schema inside an object, it could be an interface by itself that you extend because the definition of a schema is the same between a cloud event type and those things. So I think they are related to each other. So can you build it independently? Yes, I guess. That was my question in the end. But does it make sense to make it independent? In my opinion, they have related topics in some area. So I would tend to at least on the type side to meld just them on the type. But again, just my opinion. So Francesco, did you have more to say? No, well, the thing is that if my answer, but I think you replied is that doesn't make sense for the user to bring in a full cloud event as a single SDK when what it just needs is the discovery spec to the discovery service. I was trying to do something similar in the sense that as a client, I could almost understand a single SDK knowing how to deal with receiving cloud events and how to talk to the discovery service to find out what services are there and how to subscribe to them. So you can have a little bit of a conversation about the emerging client side stuff because they kind of go hand in hand. The server side, though, that's a little less clear to me. I can't. I'm having trouble struggling. Why somebody who is hosting a discovery service would care at all about it about basically cloud events. For me, right? In the way I want to implement the events in my company. I don't picture an application that will consume cloud events but never generate any cloud events. So it's kind of... There is a high chance that a service that will provide some cloud events will as well basically consume other cloud events. So that's why I didn't make that much of a difference. And the thing is the server part of the discovery is about 100 lines of code so it's not huge but that means the definition should be shared in that case. So maybe we can just leave the definition in the client part and then the server part integrate the definition from the client. I don't know. For me, the definition should be shared between the two services, the consumer and the server part. So to me, I think I can't figure out whether this is an SDK question or a question for the group at large, right? In terms of should we look to merge any potential code into one thing or keep them separate? I think, like I said, I'm not sure who's best to answer that question. Maybe we should start with the JavaScript SDK folks and see what they think. Yeah, because like the thing is then we'll implement also the schema normally and once we do that as well do we create another SDK for this one or because we could argue that maybe you just want to have the discovery but not the schema and so on and so on. Same thing. Anybody from the JavaScript side of the house want to chime in here? Is that from Slinky? This is Lance. I don't know. I need to live with this for a little while and think about it and stew on it. I mean, I literally just saw this PR during this call and I need to think about what the implications are. So I guess that doesn't really help very much but all I'm saying is that I can't say for sure yet. Anybody else want to chime in on the topic of either this particular PR or just in general how they viewed us managing potential code for the new specifications that are coming? I personally don't have a problem with it being in the SDK repos as long as it's something that's separatable. Okay, thank you Scott. Just out of curiosity, let's say they did live in the SDK repos. Is it weird to have a server side component like a discovery service be under something called an SDK? Sorry, we'll just reference. Is that against Scott? I think the SDKs are intended to be referenced in limitations, right? Yeah, that's true. If you think about that way, then yeah, I can buy that. The thing also is like it can serve the content but it's not serving it by itself. It doesn't include any servings like server parts. It's just include the code that can answer to a server implementation. So it's like a helper more than the full implementation of the server side.  So it's not like... I would completely agree with you if there was like a full implementation of Express or like something that really run the serving part. But the SDK won't start listening on any part when you run it. Okay. Lance, were you going to say something in there? You got shot again. I mean, I guess I have a few just sort of unstructured thoughts. One is that like having these not in the SDK repositories seems like it would just create a proliferation of new repositories because they're really probably wouldn't... It would be good if these were implemented in more than one language, right? And then, you know, there's already networking code in these SDKs, or at least in the JavaScript one, to send and receive cloud events over HTTP. I'm not sure that this is really that much different. And it doesn't seem very big. Yeah, that's right. The size of the repository that much. Okay. Well, that's good then. I think it doesn't seem to be a whole lot of resistance than at least considering it. I do agree with you, Lance. The proliferation of SDK of other repos would be a bit of a concern. Yeah, that was my share too. And to answer to Slinky, yeah, you're right. Like we should do free, but then I mean, if we start doing like free repo. It's kind of hard to read for someone who just joined the cloud events. I already had that kind of that struggle, like when I stopped pushing my team to look at the cloud events, I had like tons of questions. So I think the simpler, the better. Okay. So we'll see how this goes in the JavaScript repo peer review. Slinky, your hands up. Okay. So as I said in comments from, I think it's fine to keep it to have one repo where we want to push all the code to implement our specs. But then let's not forget that we start having problems like managing the versioning of the projects. You know, stuff like that, which may be complicated at some point. So, as I said, if discovery spec doesn't depend on cloud events, then it's fine for me if we put, for example, in SDK Java, some sub modules that doesn't depend on the cloud events modules. But then at that point, you start having the problem of having the same versioning for this project. Do you see what I mean? So I'm okay with that. But let's think. Don't worry. For me, nothing is written in stone. I mean, we can start. We need to like to change. We can dive up. Oh, yeah, of course, of course. Okay. Any other questions, comments? Okay, cool. Thank you, Remy. So as I was trying to play with implementing the discovery spec, there are two things that jumped out of me. I wanted to get people's opinions on these. First of all is pagination support. I realized that the number of services could be quite large, which typically then means sort of pagination. And I was wondering whether anybody had any preference in terms of how to actually represent this on the wire. I saw a couple of different flavors out there when I was just doing a quick search. And at the high level, I think there's this notion of like what GitHub does, which is they don't necessarily touch the body of the message. They add additional HP headers telling you how to get the next chunk. But then there are other implementations and it doesn't show up. Oh, maybe I didn't paste it here. There are anyway, there are other other implementations where it's actually part of the payload itself. There's like an extra wrapper around the data that says, here's the previous, here's the next chunk if you want to do that kind of stuff. I personally have a preference for not touching the data itself, but I wanted to, you know, hear from other people. And then the other aspect of it that I wanted to get people's opinions on is when you actually do the chunking, do we want to head down the path of it being assuming that things don't change very often. Therefore, you don't have to, as an implementation on the server side, you don't have to worry about some sort of transactional thing, right? Where you like run a query and then people iterate over the query set because your data is changing all the time. You don't want them to have their enumeration all messed up because things keep changing. Or, you know, do we say no, it doesn't change very often. Therefore, we don't technically need to worry about this. But then the question is, when I notice things like this, it's like, okay, is the page size dictated by this number here, right? And that gets a little bit awkward because what if someone passes in, you know, I want just page three and page size is 50. Well, that's going to influence your page sizes. And if the page size changes every single time you do a query, how does that, you know, how is that going to work? You know, it could get kind of funky. And I thought, okay, maybe it's more of just an opaque string that passes along. And then the server side knows where to do that opaque string and to figure out what the next chunk is going to be. But then he has this persistent kind of state. Anyway, there are a whole bunch of different options that I saw out there. And I just wanted to get people's opinions before I try to attempt to write a PR on this. So let me pause there. And Ryan, I'll let you speak. Yeah. So I definitely have some opinions here. I will say to your first question around whether the URL or the pointer to the next chunk of results should be in the metadata versus the payload. I think that's definitely in favor of the metadata. And I'm saying that is, we actually put it in a payload. And that has caused me a lot of personal heartache. That I can, I can try to explain a, a secrecy when I have some time. I think with regard to how the, that that pointer and all the information that's required to get to that next chunk is included in the URL itself. My personal opinion is that we can't be too opinionated here because a lot of these things are very implementation specific. So things like result size and also where in the results that you are different underlying systems and databases implement those differently and have in my experience different performance characteristics. And I would personally rather not make assumptions about what the implementations are going to use. And, you know, start with more of the approach for the opaque string than breaking it up into things that make assumptions about the implementation. Okay. Thank you. Remy, your hands up. Yeah, sorry. I might have missed what you said. Yeah, it's just for me. The server should be quite simple. So I would not be in favor of like having opaque string or something like that. I think if the client is messing around with the page size while he's browsing it, he's on fault.  And I don't think those data should move that often in my opinion, even if you created new service, I don't expect people to have like a new service every five seconds. So I would consider that it's fine. Not refreshing. And even if the result change, if by mistake you are browsing it during a new push to production, so new services, then it's kind of a faulty one. But I don't think it's going to change the full behavior of the cloud events because obviously that means it's just new events. So keep in mind, this isn't for cloud events. This is for the discovery spec. Yeah, I mean for me the discovery spec is about knowing what cloud events are on the service side. So I mean, if you don't have that definition, is that definition is a bit wrong at the moment you ask because there was a deployment in the meantime? I don't think it's a huge issue. In the last case, you just re query and you'll get the right answer. Okay. Okay, well thank you guys for your input. May I ask some more more directed questions just get your your feeling on this. Should the client, I think it's important for the client to be able to say how many requests it could handle at a time, right? It may be a very resource constrained client and maybe you can only hand or handle a couple of services coming back at a time because the size of the service each service chunk could technically be rather large. But does it make sense that the client be able to specify the number of items on every single step as it's iterating through everything, meaning should they be able to change it on each iteration or once they set it once for their queries, they're stuck with that size all the way through. Anybody have an opinion on that? I guess because I'm going to kind of asking is whether the user should be able to change this number here on every single query. When that happens, usually there's a some sort of hash of the element that you're referencing from and then you want to ask for account and then at the end of the payload, there's another reference to say where you are in the list. Rather than like a page, there's a I'm at ABC 123. I would like the next 100 elements. Right. I think that's I think that's closer to what this is saying. Right. This is saying this references the next element and I want the next 100 after that. Right. And that makes perfect sense to me. It's when you have situations like this that it gets less clear to me. Right. Is this saying I want the next 100 or each page size is 100 and I want the next 100. Because I think right because if it's a paid size, that's going to influence how big each page is. Right. Well, so consider the situation where you have a schema of, let's say 100 different things and 5% of them are. Giant schemas. So you're each page, even though I have the same amount of elements will be dramatically different sizes. So I don't know if you want to talk about element counts or. Payload size. That's a whole different aspect that I wasn't thinking about, but yeah. Okay. Let me think more about that. Okay. Anybody else want to chime in here with some thoughts for me to consider as I think about a PR for this. Okay. In that case, the other one that popped up as I was implementing it was I realized that as a client. If I'm periodically querying. I need to be able to have a unique field. I'm sorry. In a mutable field in each service to know that that field will never change. Because that way if it does change or it vanishes, I should say, then I can be assured that that service is gone. Now, another one may have popped up with the exact same bit of metadata. You know, exact same name, everything else, but because of this unique field. As is now no longer peers in the results set. I need to think of it as a completely new service, whatever that means from a client perspective, right? And so what I was thinking was making the service name be that immutable field. If we don't want name to be immutable, because people may have fat fingered it and they want to change it. Then we may need to come up with a. A more normal immutable field like an ID. And use that going forward and say, look, we don't actually use this for anything, but if we need it there for this. Consistency check kind of thing or. You know, newness check, whatever you want to call it. Anyway, I'd like to, I'd like some input on that. If you guys want to think about it and comment on the issue with self, but Jim, your hands up. The service name is informational, isn't it? Presumably it's not. It's probably more product related. Yeah. The events themselves, presumably they're going to be pretty durable. You're not going to, you know, discard an event type and then suddenly recreate it with a completely different. Schema attached to it. So I could see, you know, as we always do, yeah, our product teams turning around and, you know, rebranding things and putting, you know, events into different families, but I'm not quite sure what the intention of the value is, but it does raise an interesting point of.   Yeah, I think that's a slightly different topic, but I think it is, but it suddenly struck me when you're talking about changing things, it led me down that road of, Okay, well, what are the scenarios where you're going to change something? What would cause you to remove a service, for instance? And I don't think you should be able to just blindly remove one without having at least the capability to say, oh, it's changing or it will be going away. Yeah. I think that might be worthy of a separate issue to bring up to have that discussion. So going back to this one, I think I'm leaning, if I understood you correctly, Jim, I think I'm leaning more towards what you were saying as being accurate, which is even if we expected the name to be kind of geeky and not necessarily human readable, because that's kind of what description is for, I just can't help but get the feeling that someone may change that name from time to time. They may change their product name and therefore they want to stop calling it GitHub, they want to start calling it Foo Hub or something like that. But everything else stays the same and they want everybody to think of it as the same service. If anybody shows this name to their clients, though, they want to stop saying GitHub or something like that. So I'm leaning more towards saying each of these things needs to have a unique identifier that's immutable and that's for no other purpose other than this check that we're talking about here. That way we don't have to worry about fat fingers or anything like that. Anyway, Remi, your hands up. Yeah, for me, what I understand from it when I did the implementation is basically you just have a name, but it's not really mutable in the term of if you change, it's like a new service anyway. So I don't understand why, like what is the interest of immutable because if you rename the service, it's still a new service and the discovery, the way you match it, it's not going to be the same anyway. So because we, from the specification, the discovery is based on the name or maybe I did the wrong implementation and for the text, it's based on the type. So it's already kind of immutable in a sense. So I think the scenario that I'm thinking of is, oh, we only have three minutes left. Tell you what, let's take this offline because I don't think we have time to dive into it deep, but I do think it's important that receivers of this information be able to know when something changes metadata versus it vanished because I think as a consumer of this information, I may need to do two different things because I may have my own customers who are using the service and they need to know whether their service just vanished and then down they need to pick a new one to use or stop using it versus, oh, the metadata just changed its name, therefore everything still works. It's just when they go into the UI, it's going to have a different name there. I do agree if you change the name, basically the subscription, you should automatically unsubscribe any clients in a way that because you may disappear. So that's the problem though, right? That's the problem, right? Because if all you did is you change your name, but you don't want to disrupt any of your people who are subscribed to you, you definitely don't want to unsubscribe them, right? Because a simple name change should not screw up any existing subscriptions, at least in my opinion. But is it us to decide or just like the guy who implements and to take the decision? No, I agree that it may be someone else's decision to make. We could choose to say something one way or the other in the spec, but if we leave it up to the implementation to decide, they still need a mechanism to be able to make that choice themselves. And if we don't give them a unique field that's immutable, they don't have a choice. And that's where I'm worried about. But anyway, we're running out of time. We can talk about that through the issue itself. Okay, but thank you guys for the input. Let me see. Okay, that's it for the agenda before I go back and do roll call. Any other topics you want to bring up very, very quickly. Okay, in that case, we had some people drop, unfortunately, I don't think Sam's there anymore. I'll see Paris. Nick, are you there? Excellent. Perfect. John, are you still there? John? All right. And Manuel? Yes, I'm here. All right. Gustavo? Gustavo? Okay. Cool. All right. Did I miss anybody for roll call? All right. Thank you, everybody. I guess I should have asked. I guess you did want to talk about your SDK stuff at the top of the, where we want to talk about this thing. So, okay, yeah. So thank you, everybody, for joining. We'll talk again about a minute or so. We'll start up the SDK call. Okay. Thank you, everybody. Thank you. Thanks, guys. Remy, I apologize. Is that hand that you have up? Old or new? It's old. Sorry. Okay, good. I assumed it was old. I wasn't 100% sure. Yeah, I'm managing my daughter at the same time. Yes, child duty at the same time, sticking phone calls is not easy sometimes. Okay. Any other topics people want to add to the list? Well, that's a good question then. Is there anything else you want to talk about relative to your discovery PR? Okay. In that case, do we have anything to talk about at all? If not, we can adjourn after about a minute. Yeah, because, yes, I don't know if, yeah, I'll wait for a lens review and another grant to push something. I think we kind of talk about including it in the SDK. And we, for what I understood, we all agree that it's okay to integrate in the SDK for now. Okay. I want to just let you guys know I haven't had a chance to investigate a security email address. I'll add that to the list to make sure I don't forget. Okay. Any other topics then? Otherwise, we're going to call it. Okay. I think we're done. I like short calls. Okay. Have a good day, everybody. Thank you for joining. All right. Thanks, Doug. Okay. Bye. Bye, people. Bye.