 Hey guys. Hey Doug. Good morning. Good morning Vlad. It's been a while. Where you been? Yeah, sorry for disappearing without a trace. I retired and I started with a lot of relaxation. You retired? Are you kidding me? It's my third time. I never managed to stay retired more than four months because I get bored. We're having a good taste now. We'll see. You're so funny. Hey Tamer. Hey Doug, how are you? Good. Hey Lou. Hello Clemens. Sorry I missed you. I was checking email. Who was it? Hey Tommy. And...Honkly? Honkly? I apologize. I'm bad with names. Yeah, honky. Okay, thank you. This isn't your first time on the call, is it? No, actually I was here the week before. Okay, that's what I thought. Oh, actually that's a good point. Let me check something here. There were a couple people who recently joined that I did not get their company affiliation. What company are you with in case you want to be affiliated with the company? Ah, okay actually I think I did put that. Hold on. Because I remember somebody adding somebody on the pop-up recently. There you go. Already got you. Cool. Okay, never mind. Bad short-term memory. Hey Lucas. Hey, how's it going? Good. How are you? Good. And Lance. Hey dad. Hello. You're close. Yes, hello. You're a freshman memory close. Three weeks? Yes. Okay. You bum. Okay. It's Germany. I know, I know. That is how it's supposed to be. Yeah, that's what you say. Envith? I'm not sure how you pronounce that. I apologize if I'm, oh, no microphone yet. Never mind. So Klaus, when you're on vacation for three weeks, do you not even check your mail and just let it all pile up? Well, I try to. I find that if I don't do my mail when I'm on vacation, it's just, it'd be worse when I get back. Because then you're spending like the next three or four days just going through email. I literally throw the email account off my phone. And I also log on from teams and I never look into anything during those weeks. Wow. Yeah. I'm, I'm super consequent on those, on those things. That's amazing. Yeah. All right. We'll follow up on emails. It's safely ignored them. I feel guilty. I actually have an out of office message which says, I'm not going to look at your email. If you want something, send me email on the day when I come back. Okay. I got another question, but let me, let me do my admin stuff here. Brian, are you there? I'm here and plus one to the deep disconnect account. All right. Christian morning. Envith, I apologize if I'm pushing your name. No, you got it perfectly right. Okay. And which company are you with if you want to be associated with the company? I work for Hello Fresh. We're based out of Berlin and Germany. Okay. So this is my first time because I stumbled upon cloud events when I was looking through something. So I just joined the scholar of curiosity. Cool. Well, thank you for joining. I know I'm going to get this one wrong. You Quinn. Why are you Q, you Q, I, Q, I, and G. Are you there? Okay. What about Scott? No, no, no. Mathias. Hello, everybody. Hello. Okay. That's someone else joined. Oh, there he is Thomas. Are you there? Yep. Excellent. I'm missing anybody. You couldn't, you couldn't. I apologize. There we go. Got it. And which company are you with if you want to be associated with the company? Adobe. Adobe. Oh, oh, interesting. I recently was looking into you guys for some video stuff. Interesting. All right. Let me just get the last couple of folks calling. Are you there? I am. Good morning. Good morning. Someone else go by slinky. Are you there? Hello. Hello. And Ryan, are you there? Yes, I am. Hello. Hello. Okay. Did I miss anybody? Oh, wait, we have another Christian. Me. Remise. Yeah. Okay. I got you. Okay. And then there was another Christian flying by. Yeah. I'm going to go to someone where it was a, there is TZ. OV. Well, OV. Are you there, Christian? All right. Let's go ahead and get started. Probably going to be a short call anyway. Let's see what, okay. Community time. Anything from the community that people like to bring up. That's not on the agenda. All right. Not hearing anything. We do have an SDK call scheduled for this week. I believe as of right now, there's only one very, very minor thing on the agenda. Okay. So I'm going to go to the community. Yeah. Please, of course. Yes. And, and, um, And ask those folks who are, who are, who joined out of curiosity. What specifically, specifically the curious about. Okay. Since I was the guy who said that I'm going to go first. Yes. So basically we, we were trying to add hello, fresh. I don't know how many guys, if you know, hello, fresh, I don't know if you know, if you know, I don't know. I don't know if you know. So we had a really, really good subscription company. That's based out of Berlin, Germany. So we had a, we had, we were trying to tackle a problem where we wanted to store some, some of the events that mobile app or the front end would publish and then we will store it in S3 or somewhere for analysis in the future. just from one link to other I just and then I just came across the cloud event spec and here I am. Okay great thank you. Anybody else want to chime in? All right cool moving forward then we do have an SDK call scheduled for this week but there's only one minor item on there probably not worthy of having a call just for that take it offline especially since it's mine and I won't be able to join the call but if you do have other topics please add it to the agenda before this call ends and then someone else can run that meeting since I won't be able to make it. Okay Tim or anything from the workflow side of things you want to bring up? Yeah thanks as far as what we're currently working on we're adding extension points to our workflow definitions such as KPI and simulation so those are the extensions that are specification provided and allow you to add like non-execution type of stuff like key performance indicators or information about simulation and stuff like that so that's as far as working goes and kind of like just shameless plug our next meeting is August 3rd and we are actually finally on the cncf public events calendar which is a big plus so all right any question yep thank you any questions from all right all right moving forward before we jump into the prs anything on the agenda that I forgot to add that we should talk about okay um this one Klaus you're still not convinced um I'm sorry it's okay um so so Klaus it seems creeping on wrong it seems like you're you're just not sure we actually need this so I guess my question for you is how would somebody as a client receiving the list of services um know whether in any particular service is an existing one just had all its metadata changed and therefore they should just do an update versus it's a brand new service by the same name I guess so you're assuming the name needs to be immutable yes or if you um change the name then it's technically a new service what do people think about that I do agree with Klaus on that one I was not facing but I do agree so if someone had a typo there was a company buyout and they needed to change the name from IBM something to Microsoft something even though it is the exact same service the name cannot change correct so my point is that those services are and the metadata are provided I mean they are developed by someone and probably then aggregated at some place um in this discovery service and and so this metadata is kind of in development artifact and if you had to um put a ggid into this and maintain it I don't know it feels a bit awkward okay alternative would be to generate that ggid inside that discovery service but then if you update the metadata as developer um how would that this then work so yeah so you said something interesting there um it was always my assumption that the idea is generated by the service itself it would not be something the user would explicitly set when they add a new service to the system does that change okay but what does that mean by the service itself so um rephrase the question I'm not quite sure I'm following okay how would that work the service itself generates the uuid the the well that that's not that I'm not sure I mean the the the rest of the data is provided by someone the metadata right what point would then the uuid be generated right so it gets generated by the system then the same way the the uuid is generated by this system in kubernetes right um it's returned to the users when they query the system so they could see it but that would be the way they uniquely identify it right because I mean if I'm the only one that thinks not being able to do a rename is is is crazy then that's fine I'll let it go so it's just from my experience in kubernetes I hate it I hate that I can't rename things in kubernetes kubernetes i'm sorry kubernetes the the uuid is generated and identifies then the resource in the context of that specific cluster correct and that's what I was asking before in my previous comments so what I was targeting at because I was actually looking at the um specifications uh for on the kubernetes end how they define the uuid they have for resources what context would this be here sorry no so so I I I guess I'm not seeing much of a difference because I believe the uuid in in kubernetes is globally unique I think I'm 100 sure but I thought it was supposed to be unique across clusters that you can do imports and exports across clusters and in particular what's the term they used yes but it's the resource on that specific cluster then even though it's unique yes well all right I had to go back and double check and see what happens if you were to do an import export whether it retains the uid or not I can't remember export the uid and they are unique for cluster so when you do an import it gets reset sorry body issues uh I think the version get gets bumped like for an update isn't it I might be wrong on this I think version is different than ID though but anyway so Clemens were you gonna say something earlier you know you might have gone chopped off uh yeah sorry um since this is not the name but the the identifier I don't see that's much of a problem with a problem which direction I'm not sure if that means you're in favor or against the PR well you are saying you're saying that you hate for things not to be renamed right and but this is not renaming this is re-identifying and that's that's different so I agree I agree with with the the name um the ID never changing yes yes if we set the PR the ID is immutable that that's a given the question I think in front of us is do we really need this or should we just mandate that name cannot change and that name becomes immutable I think that's the question before the group ah yeah names names being changeable is something that's probably more that's something that's more convenient and that's why we would have the difference because names can be there can be typos or you can go and change your mind or you can you you start with a particular name and then the marketing department comes around and gives you a brand exactly etc exactly those are the things that I wanted to avoid because because these I mean even the examples we give here for name they're not exactly unique in that sense right I mean the word storage is is pretty generic right and as you said someone could come along and say hey don't screw up your existing customers because they're still using this thing but you know what we need to call this IBM storage but who's generating the UID in your case because when I implement the discovery it makes sense to me to put a name but the UID if I generate it on the fly it won't to understand so that means I need to thank you yeah I was assuming it'd be generated by the discovery service itself in other words the system that's that's persisting this metadata and it would just generate a unique ID for it but then that means the discovery service needs to have something to store to store it while basically but maybe my implementation was wrong but my in my implementation it's just driven by the code so I have nowhere to put those kind of generated UID in or inside the code or I create a JSON next to your code but then I find it not clean so you're writing a stateless discovery service yeah so basically for but again maybe it's because the way I I didn't understand it was not the right way but in my opinion when I create the service I was able to create to explore the discovery service while waiting while creating the service by itself and so the discovery service is stateless is just inside my code and just with the three lines of code I expose them to discovery service with all the different services but that's maybe my interpretation that goes on yeah in that case I would have issue yeah in that case I think you'd have to change your code to include another field called ID and and stick a UID in there the same way you create a field called name and you stick some name in there right because everything's static to you exactly yeah and then it's like the user to create it but I don't see the added value because I think the name rename it's fine to expose basically the same service with two names because if you rename at the end what you end up doing is expose the same service with two names and then a human can say okay like I know that I'd be like the Microsoft is deprecated because it has been put by IBM so within one year I'll have to change this name from like Microsoft to IBM but is and then as a discovery service you just expose those two services and the other two names and like I say I manage the migration yeah from a programmatic perspective I I have real concerns about that because as a person writing code is on a client site I would have no idea what to do with that because they would show up as two different services and but they're really the same service that means you add the constraint that the discovery service needs to have a state so now you we need to have a database to run a discovery service so the discovery service is no no it doesn't have to right because in your particular case you have everything hard coded in your code right so in your particular case you'd hard code the ID yeah that's not really good and then I have to explain to the user using it that they need to generate a fake like whatever you ID and put it there wait wait no wait no wait I really want to understand your scenario why would a why would a user need to generate anything but because the UID like the code won't be able to update itself like the as it's static inside the code I think I should go like we can have a separate meeting on that and I think we need to prepare the demo and the discovery service so you might understand more the way I was thinking it maybe like and challenge me on that but I will like if you have time in the next week you know we can probably yeah yeah because I'd love to understand your scenario um because I don't I in your particular use case I don't think ID is any different than name at that point everything's hard coded in your code so I don't think there's any difference there but yeah let's talk offline better yeah Ryan your hand was up I want to pick on you since you were going to say something um so just looking at this with fresh eyes I don't have a whole lot of context but um what is a little confusing is the first two sentences of the description are a unique identifier for the service and a unique identifier for the service for both name and ID so um at the very least if we move forward with this we might want to clarify the difference um uh and I know it's clarified a little bit um technically but like what are what's the intent of how this is used versus ID gotcha yeah like I could see that being confusing I can work on that but I still think maybe we're not going to come to a resolution on this call unfortunately but I still think we need to to resolve the overlay the the high order bit which is should name be immutable right because I think if once you make that decision I think it resolves everything else right if name is immutable then we don't need ID if name is mutable then I think we need something like ID but yeah so I'd like to get a sense from the group is name can name it be changed by the by the provider so me for me no okay like if you change you create a second service even if it's identical so no class you're in favor of keeping it immutable right well I wonder if it's really an identifier if you make it mutable well I think I think Ryan is correct this text here might need to change yes I agree it's I still think you probably need name to be unique because I think it'd be very confusing if you had two services both called github from a user perspective yes but I think I think the wording here is a little bit awkward because it's not meant to be sort of well we can talk about later but I think I think the wording here needs to be changed slightly I agree with that I don't know a lot of quiet people on here if I may the thing the the fact that you you kind of acknowledge the fact that it should be unique it's more logic for a human that it's unique kind of is an argument in a sense that it's mutable yeah but but you got to understand there's a difference though right this name needs to be unique at any one point in time in the sense that when you look at the complete list of services you don't want to see github show up more than once hopefully everybody agrees with that but the fact that it can change over time is okay because that just because the uniqueness here is just to make sure that the user doesn't see duplicates in his list right the uniqueness of id is there to unique is to be able to unambiguously identify which service you're talking about when you get metadata and that's why it's it's more for internal uses I would never expect the idea to be exposed to users ever this is like this is like you owning a static IP address and then you're using a DNS name for it right now that's ibm.com and then once this reverse takeover is over it's going to be redhat.com but it's still pointing to the same to the same endpoint maybe a good comparison yeah yeah but so if I continue to review what you usually do is you have the old DNS and the new DNS pointing to the same IP because like the way we will do the migration and at one point in time you remove the old one so yeah for me a name really implies something which might change over the time and and this uniqueness of a name it's going to be hard to achieve I'm not sure in which scope you were thinking of having a unique name so I am in favor of having a uuid per service and yeah as we know and you showed the examples I mean storage as a name and that might be people choosing for the name just this simple storage and then I'm pretty sure somewhere else storage will pop up and then you're really confused as a as a client and user of these discovery services then you have a storage there and the storage here and which one is which and I'm in favor of an ID okay John your hands up yeah I guess I'll say the same thing right the the changing of the names is is totally different from from a hard ID that you're going to use and rely on as the actual identity of the underlying service itself as it's alive I guess my question to you Doug is do in terms of the what some people call the lifecycle of this thing like are you expecting that to live across multiple iterations or do you envision the ID being used as each you know like each release of the service having a different ID that's an interesting question my initial thought was it would oh it would it would be the same cross versions of the service because from the end user perspective it is the same service now if a producer chooses to treat version one and version two as completely different services then then yes I think they'd be different IDs and you know the fact that they happen to share the same base name and then they differ in the v1 versus v2 part of the name that's just an interesting side of that's just an interesting bit of trivia right at that point um big but if they really are separate services then they get different IDs but if they're the same service and one is meant to sort of replace the other one then I think it's the same ID right so then my my suggestion is to put some you know like into the primer or something like that some clarification around you know those that variability right another one yeah I mean you can hear in people's comments right there's there's different distinctions of what people are gonna key off of I guess pun intended to you know to decide what they're what they're actually interacting with right and like you say different versions different people have different models of what versioning is and whether that's significant to their use case or not okay great input thank you Brian your hands up back with my naive questions again um I'm wondering if uh if the use case we're thinking about here is that somebody would have created discovery service in the past save this ID and then in the future we'll be coming back to the discovery service to make sure for example the url hasn't changed so they want to hit this endpoint again they come to the discovery service and use this ID to get the url that they should be using is that an accurate description basically that's one way to do it yeah I mean you're not gonna I'm I would be actually whether we allow them to query by ID or not I don't know that my my use case was a lot simpler it's just maybe every week some client does a query to the discovery service to say what services this does this provider offer right and as they get back that list they need to know for every single service they get back is it a new service or do they just update the metadata on existing service right and I don't know how to do that today if name can actually change but it is the exact same service um how do we expect somebody to update a url for a service elaborate a little on what you mean um so if if you weren't thinking of that use case of somebody coming back to find out what the current url for a specific service is um if the url for a service changes how how do we expect clients of that service to figure that out well I think that does fall back in the scenario described in the sense that when you do your query you'll get back the list of services you'll be allowed to identify based on based upon the ID whether it's in a new service versus an existing service if it's an existing service then you can just do a diff on each field to see whether it changed or not and url is just one of those fields right the same way the list of types might change okay yep thank you um yeah I given uh some things that I have uh seen around naming things and branding and whatnot it it certainly seems nice to decouple this uh into an ID away from the name um I think I I fall into the camp of folks thinking that yeah the name could probably change here okay so tell you what I feel like we've taken too much time on this one and I definitely don't think it's ready to be merged in any sense and I'm not her percent convinced everybody's on the same page yet especially Klaus and Remy and stuff so let me do this let me go back offline and thank you all for the wonderful feedback and go back and rework it some more and we'll revisit at some point later and maybe it'll take another three weeks by then and Klaus you'll be back and you can be wanting me merged by then and then you will have more rounds of it but at least I feel like there is more work that needs to be done on my side to help clarify some things so let me at least take the feedback you guys gave me and rework it a little and not push for any kind of decisions now because I think it's too soon okay one one quick observation about what was just said um if we define events for the discovery service yet because because it's like how do I learn about something changing in the discovery service and it strikes me that we could obviously use cloud events to notify people about changes in the discovery service just a thought sounds nice to me you want to open up an issue so we don't lose track of that uh sure I should have I should have known that that calls this work all right okay yes I'll teach you but it but it is a good idea though I do like it yeah eat our own I will I will write it down immediately okay all right so as I said I think we probably spent way too much time on this on this call um any last comments that before we move on the next item okay cool thank you everybody for the feedback that I appreciate it um okay I don't remember who opened up this one that was me oh there you go cool and you're on the call you want to talk to this one yeah basically I took your discovery description including the change of the ID and created the open API description of this API of this discovery API it's not perfect yet because I tested it with the API management in the cloud and the results are not exactly or the return value is not exactly what you would expect but at least it's a starting point and and I thought I'd give it a try to to actually file it as a PR and then it seems that no one was aware of this I didn't see any comments yet um what do people think about this in general I'm assuming people are okay with the idea of creating a an open API specification for discovery I assume right any objection to to hang that direction okay so I guess my question for you Thomas is aside from the ID thing which obviously is easy to remove um do you think the rest of it is a good starting point that we should try to merge today and just add to it as we go along or would you rather do some more changes first before we consider merging it for me I think it's a good starting point it's also executable and but it's also to try out for people to see what is actually the return the responses from this API description does it match the the expectations and that that would be from my point of view a good starting point to afterwards process issues or further change requests on that one but at least we have a starting point would be worth to to merge it already now and actually the description I took over from from your discovery nd file so it should actually match except of course I mean the id would need to be removed and of course the name still has this unique identifier for the service in right okay so for the rest of the group um if Thomas was to remove id because obviously that's not in the spec yet for the rest of it how do people feel do you does everybody on the call want or need more time to look it over or do you think even if it's a little bit off it's a good starting point that we can pr it later how do people looking to approve this today minus the id stuff and if you need more time don't hesitate to speak up just so I don't know this is one one projection of it as gamma right what do you mean by one projection sorry well one of my uh one of my goals is to make sure that the discovery API can also be hosted inside of Kubernetes yeah oh so Scott I think you're asking a different question I think you're so we in the discovery spec today has a rest API defined I think you're suggesting or you're wondering whether we will also support other types of rest APIs in particular the Kubernetes API right that's right exactly right so I think that's a slightly different question because I think all he's suggesting here is given the current rest API we have in the spec here's an open API for it exactly and actually the discovery API description already has a heading open API with with three three dots so I thought I'd give it a try for for this part for the rest API in open API YAML description so Scott I think I think it might be worth you opening up a separate issue so we can track your question it turns out whether we want to support an alternative rest API the same way someone opened up a question about whether we support query ML if that was what that's what it was called okay I will do okay okay I thank you Lance Lance says it's okay with him just to check this in now or merge it in now anybody else have any comments one way or the other because I'm inclined to to let it go in then PR or any changes that are needed but I don't want to rush it if you want more time I'm good with that too okay thank you Remy anybody else want to speak up okay one last chance any objection to approving minus the ID okay approved without ID okay so if you can make that change Thomas we can then merge that thank you everybody cool thank you okay Christophe it's weird I could have sworn I saw a message go flying by my screen where Christophe said he wasn't going to be able to make the call today but then I couldn't seem to find it later but he's on the call so does anybody did anybody get a chance to actually read this this is another PR to try to address I think it was Grant's concern about structured mode and how it structured mode versus batch mode and there was some confusion about whether it's they're all structured or different modes and all that kind of stuff and I think this was Christophe's attempt to try to address that did anybody get a chance to read this or have any commentary on it okay yeah I was gonna ask for more time personally because I started reading it this morning and I got to admit I got kind of confused when I was reading it but I was also on a phone call at the time so it may have been my own lack of attention but it just seemed like it was it seemed like it might have been hard for a newbie to try to understand all the variance nuances between the terminology but so I was going to ask for more time but I just want to see if anybody else on the call had any thoughts on it as to whether it was a step in the right direction or not Thomas yes as far as I remember the discussion was a couple weeks or even months ago that in binary mode it's really difficult to actually batch because if you look at the example of HTTP in binary mode you have hetero fields so how would you do a batching of multiple events but I haven't read the PR yet but I think this is around this this part so actually it disqualifies batching for binary mode more or less yes I think I think everything you said is true yes I think the biggest question was someone's reading the spec and they were confused as to whether batch is a structured mode or whether whether batch is a variation of structured mode or whether it's a separate mode and it was more of a wording thing and less of a coding thing I think anyway I think it's a coding thing too batched I think so my my take is that batched is bundling of a bunch of structured messages right so it's a mode that wraps another mode it's not a subset it's a it's some other thing but okay well then I said I would strongly recommend that you read it Scott because I think if I remember correctly based on what Christof said I think he was headed on the path of saying no there's really only two modes structured and binary but then there are different flavors of structured and one of the flavors is batched and I suspect that's what he was trying to say here so you may want to read it and chime in there if you think he's he's heading in the wrong direction okay anyway I'm not hearing anybody jump up and down saying that it was merged this thing yet at least for me I want more time anyway so we'll give it a little more time okay any other comments on that one okay there were two other PRs that were opened they're both I think relatively new so I don't think we can technically merge them from that perspective however I just want to double check on this one this seemed like a simple goof up on our part in the sense that we went from content from content type to content to data content type we just forgot to change this particular file for Avro um any any Avro experts are on the call or even novices on the call I think Clemens you might have you have some experience here um I don't actually think it changes the Avro output I think it's just changing the cloud event type itself right this is just a simple typo fix for us right yes okay um I'm pretty sure they're called data content on our spec yeah I think they are let me just double check no it's in the Avro no he was talking about this right he's talking about the cloud event data content type or yeah but that's the example so what's in that but the question is what the schema that we have in in that document is is right but I think it is oh you mean wait when you say schema you mean this one uh yeah look at that don't mention content type anywhere in there at all yeah I think that's generic yeah we we move that's a generic structure yeah exactly okay great yes so so then that does matter okay so I think so I thought I said I think this is just without the word data we do need to change yes correct so that's that's just a bug okay so I think it's the typo um even though it was only opened yesterday I don't think it's controversial at all anybody have any objection to trying to merge this now they want do they want to wait go okay any objection to approving okay cool I thought it was easy just want to double check because sometimes I'll make a mistake so I don't want to assume too much okay this one class um you want to talk to this one since you're going to be gone next week yes I thought I I leave you something to discuss while I'm on vacation so it's just you you started with this primer a few weeks ago and I wanted just to add a bit more to it I think so far we've been mostly or we just had use cases in there starting with consumer ones and so I thought I add a few to get the discussion started that are more about intermediaries or producers and that's what is in here so one is about an intermediary that has somehow to provide discovery for all the producers um it stands for and so it's it has to somehow aggregate what I call event catalogs of those producers and the other hand producers have also to register with some intermediary or that provides discovery or subscription and that has also to happen somehow and that's maybe also partially what I had in mind when we were discussing the studio ID thing so any questions for close okay I have one um um your your language here seems to imply certain things for example you an intermediary is said it aggregates and I agree with you that it can aggregate but I you could have intermediaries that don't I assume yes right yes I believe we might just need to tweak the wording to imply that we intentionally separated the discovery endpoint and the intermediary so but in this case it's the case that intermediary is also um providing discovery and uh subscription but I think it has to aggregate in order to but it depends how it is built but in this case it is aggregating it but was your intention to apply that that's its purpose in life is to do an aggregation as opposed to just be a front end for something well it's something like a message pass so you're such you have to consumers um subscribe to it and and want to get events and don't know about the producers so um right but okay let me ask a different question from the client's perspective the intermediary will look like the discovery endpoint correct yes maybe but it's it's not only about discovery it's also about being able to to handle subscriptions for the intermediary if it gets subscriptions from a consumer it has to um to to route those subscriptions maybe even to multiple producers if it's a something like a wildcard subscription yeah I guess I guess the reason I'm asking these questions is because I'm wondering whether I so my phrase is right so I agree with you in general that you can't have intermediaries that makes sense um but I'm just wondering whether that's more of an implementation detail or whether it's something that a consumer actually needs to know about or whether to them there's just one or more endpoints out there and whether they all point to the same physical endpoint or their you know the subscription endpoint is slightly different from the discovery endpoint they're all just URLs and it's and the the client's just going to follow the URLs right I mean we need to does the client need to actually understand the the notion of intermediary as opposed to just there's a bunch of URLs that they're going to return I guess that's maybe the the things we discuss here um if this spec is only for um interoperability between consumers and something else or if it's also discussing for example interoperability between intermediaries or I mean also looking at the other perspectives on this eventing so that's interesting are you asking whether there are specifications should talk about the APIs or interoperability between the components behind a discovery endpoint um maybe so yes oh yes I mean we we had this also when we were discussing discovery in the in the smaller round and that time we were we said that we would postpone this discussion until later on but I thought at least um reducing those use cases now um couldn't hurt interesting okay I have to think about that thank you thank you for the clarification anybody else want to chime in and ask Klaus any questions before he vanishes for a couple weeks Ryan your answer I guess with in the context of the cloud events specs what's special about an intermediary but it has to also get the information needs to to provide the service so um so far we just have this discovery query interface but um intermediary also has to to get the information about the producers so they have to hand over the list of events they may produce things like this your questions okay um so I think this was so was just open yesterday so it's too soon to merge anyway um but obviously if you guys have any questions please open up issues or comments in the PR and they may have to wait for Klaus to get back we'll see all right thank you Klaus anything else you want to mention on this one Klaus no I don't think so okay cool thank you all right in that case technically we're at the end of the agenda um for anybody that owns these issues um actually yeah so I I need to rework the pagination stuff I think the rest the other four are owned by Francesco so Francesco are there any of those issues that we should discuss now or ready to discuss I think they all have some outstanding work items associated with them don't they well yeah I just want to point out that we are looking for feedback in the first one oh yes point yes so please review that one again um I know Lance you made some comments just a few minutes ago so thank you okay with that we're on to discovery spec or in Eropa on the discovery spec um for myself I have not had a chance to do any coding for a couple weeks unfortunately um Remy is there anything from your side that you want to mention no you're working on something yeah uh just if we can try to meet during the week I'll pin you on the slide to try to find a slot together it could be great I think to do a well station yep sounds good okay anybody else how do you input their thoughts anybody else thinking about implementing anything in the space to join the interupt well um I am um still I still am there yeah uh I just need to do KubeCon stuff first I got a comment on that in a minute yes but uh Manuel go ahead yeah I'm uh still checking but I think I might be interested to join the effort so if you have a meeting in between uh please count me yeah we haven't planned on scheduling meetings yet but that might not be a bad idea I think maybe we just need to get past some of the current flurry of activity people are doing like for example Scott mentioned KubeCon and stuff like that so we will look to set up a meeting in the not too distant future to get everybody on board and use that as a forcing function anyway Slinky your hands up well if we have an open api specification schema we don't need to do any work to implement the client that's very optimistic of you no no I mean I worked a lot with open api and most of the times there are a lot of co-generators out there and most of the times the co-generator really does most of the work yeah as I said it's very optimistic of you that's Thomas your hands up yeah yeah just to add to that one because I tested the open api aspect with the azure api management and yes of course you can just echo the examples which are in the specification but if you want to have something like returning multiple services or returning a specific service or or having a matching thing I'm not sure I mean I'm not an expert in sophisticated generators of code but I think they still need to do some coding for it Doug you're on mute crap I was talking for five minutes I apologize um that's technically the end of the agenda um any other topics people want to bring up all right going back to the uh attendee list um I got me well ginger are you there I am sorry I was a little late yeah no problem uh Sanjay you're there oh actually he dropped off and then someone else just joined when I saw it where was it somebody's name went flying by a second Daniel that's it are you there yes I'm here excellent all right um anybody else that I missed all right cool in that case I think we're done um let me just double check though for anybody doing it was not interested in SDK you're obviously free to leave right now but let's just double check and see if I have anything on the agenda so nothing except my security email thing I'm inclined to this okay anyway else none SDK stuff you're free to go SDK folks quick question for you we recently created this email address um so that we can receive emails or sign up with different sites for doing testing or build stuff and stuff like that it is a private email address that only the maintainers have access to um somebody suggested we need an email address for people to raise security concerns about the SDKs any objection to using this email address for that purpose that way any email would technically be available to all the maintainers I would just add a the plus security or something a little tag thank you for reminding me yes I thought about that earlier today based upon the other conversation thank you well I would uh to be honest I think it would be better to uh because you know the security it's for each SDK maybe just cncfcloud events plus the name of the SDK like plus rast plus java I think it's fine for security so we uh for example in SDK Java we can say for any security concerns write to cncfcloud events plus java at gmail.com I think it makes more sense any comments on that that's fine too just some way to some way to limit it I mean it all goes to the same email address right it does but uh having having a standard uh having a standard extension plus security or whatever that's specific I think is useful otherwise people might just plus you know oh I think it's java SDK so they might they say plus java slash SDK or you know there it becomes less useful for filtering purposes uh if we don't have like use this one uh extension okay any objection then to doing to using the email address but then doing a plus with the SDK name at the end of it or in the middle part for the outside I think okay I will take the action item then to do I guess create some PRs and the various repos to add that to the readme's or something like that I'll figure it out okay any other topics for the SDK side of the house okay sorry I have I have one really quick one um yes sir I'm maybe two I'm going to ping the slack channel for SDK maintainers to contribute samples of uh several exercises for the coupon talk so look for a slack message there uh I need to work that out and then um I had so I'm sorry I had something else and I lost it so I guess so why while you're thinking the other thing I forgot that was going to mention the previous call is uh since you mentioned coupon Clemens and I did do the recording for coupon China and EU it's actually the exact same recording we just used for both we removed the location specific information from our charts so it could be reused I believe like if I did it correctly I've loaded both the presentation as well as the video into our cloud events google drive thing um if for some reason you folks can't get to it or I put in the wrong spot let me know um but I think it uploaded the right one um but it is available for you guys to look at if you really want to okay and Scott I remember the second thing about a CLI repo for which so right now we have the conformance and that's turned into more of a more of the cucumber tests I wonder if people might be interested in a cloud a cloud events CLI to help kind of send and receive and do other things for cloud events would do pearl plus plus but uses cloud events are you thinking about having all the SDKs move their CLI stuff into this repo no no it would be a separate cloud events CLI so you can send and receive and basically what's in the conformance test that I built but maybe we can make it better and what might into that pearl no make it better it's it's in go oh it's in so but then I guess I'm sorry I'm being dense what's the difference between say that go CLI versus the going SDK CLI the going SDK doesn't have a CLI I see what you mean it's just a library got it it's an installable tool that you can use to interact with cloud events I'll make an issue and we can debate about it well let me ask the question what do people think just a question how does it differ from putting that code for the CLI stored inside the SDK go I mean you could do that I think what do you think about that Scott well I think the implementation doesn't matter as much as the the command line interface so it's a it's not intended to be a a library at all it's intended to be a thing you install yeah exactly you you we could do the same putting that in the SDK go right we go yeah but it should work with languages too it's not it's not necessarily a go thing okay lance your hands up yeah I'm I I would like that I would like it for I like the fact that the conformance I'm bumbling here the the cucumber stuff would be nice to have as a a what do you call it a sub repo in the SDKs but it's got all this it's got the CLI stuff in it that kind of clutters everything up so at a minimum I would like that stuff to move into another repository yeah I turns out I use that thing all the time and so I'm suggesting that we take the code that's there and move it to a CLI repo in cloud events and then leave the conformance as just cucumber yeah that would I would like that personally okay anybody else want to jump in there okay so do we need to actually open up an issue and discuss it or do we just create the repo now people and you want one more time Doug give me more work come on man okay tell you what why don't you ping the slack channel and if there's no objection to the slack channel then we'll just open up the repo and you can go for it how's that sounds good okay cool all right any other topics nope all right in that case everybody have a good rest of your day thank you all right all right everybody bye