 Hey, Eric How's it going slightly tired, but you know I can't complain all things considered Yeah About the same tired I don't know why but yeah, mind the simple excuse I stayed up too late. Yeah, I Wish I could blame it on that at least last night. I think go to bed that late. So I have no excuse Other than just getting old And then there's a theme here There's a problem is that I have to Drop my daughter very early at 20 to 6 in the morning. So I have a good excuse So you get to drop off at school. Yeah, and she's going to be a nurse And All right, hey Tommy Lemons Mr. Clemens are you there? Yes. Yes. Yes. Yes, I am. Yes. Yes. Yes Okay, and Vlad good morning, bud. Hello You always sound so chipper Vlad. I love it Well, just after this meeting I'm going drinking so That is so funny Christian are you there? Hey, and mr. Mark Happy happy Thursday How uncle are you there? Yes, excellent. Thank you. Actually, there was one person Did not get their company affiliation You know, I love the things are on the web, but sometimes they are so slow Come on scroll scroll. There we go. We'll catch up with him later All right, Remy. Are you there? Yep. Hi guys. Hello Hello Hold on a sec. There we go. Okay Lucas are you there? Lucas Hello, hello, gotcha and Lance Hello, I'm here. Hello, Brian Hello, hey While we're waiting We are gonna have a call an SDK call this week And the max have quite a few things on the agenda. So for anybody who wants to join that calling me Let's take a look at it While waiting or in advance the call Hello, Hines Hello, sorry was on mute there. No, you're all good. Just a One more second or so then we'll get started He's got all right, let's go ahead and get this thing started All right Okay, community time anything from the community if you want to bring up that's not on the agenda I've got a question here. Yes, sir. What's the status on doing cloud events in AWS? I've got some questions on that from some friends I know there were initially talks about doing custom transports for SNS SQS, whatever that got Cancelled and it was gonna be implemented in the SDK and In the SDK the conclusion was that it was gonna be implemented somewhere in AWS land and not in the official cloud events SDK because it doesn't really make sense And it seems that nothing happens. I think all SDKs caught us which SDK I Checked up. I have the peers in my history. I can link them soon ish But it's unclear. What's the status on that? I know team from AWS was in this group But he's no longer with AWS Any updates on that would be good Anybody In the past I was just dumping the cloud event to a JSON and putting that in whatever transport, but it's not ideal Anybody have any comments on that? I know nothing about what's going on with AWS with this stuff personally I mean we've had a pretty consistent Standing around proprietary protocols. Well, we do have that Wiki page lets you point off to ones that use cloud events, but We just need Amazon to like actually make a spec that's that describes how they would like the binding to happen Yeah Slinky, did you want to say something your hand was up there for a sec? Yeah, as far as I remember I think I discussed with Scott about the fact that if we have a spec we can we can implement it, right? But we need a spec first But I missed that for a second. What what spec are we talking about a? Binding spec for proprietary protocols Like for example go lang supports pub sub pub sub has a spec that's hosted in the Google GitHub repo So we use that for the how to do translations if The question is the question is shall Shall we do AWS's work if AWS doesn't care exactly and My inclination is to say no, which should not surprise anybody That doesn't mean that I'm gonna keep anybody from doing that work, but We also have good rules for whether that needs to live and that is not here Hines your hands up. I Just wanted to comment that having done a little bit of stuff lately with AWS I agree. There is nothing spec. So that is one of the issues, but you can't just say AWS Are we talking AWS SQS? Are we talking kinesis? If it's kinesis, are we talking data stream or are we talking? There's like four kinesis like they've got lots of different potential transports So it's very dangerous just to say AWS because it's actually a suite of potential Transports not one transport and for AWS and for AWS or sorry Amazon MQ Since that is standard space and it's bad as based on a active MQ There's a binding and for all the other things and for SQS arguably because a send is just a post That can also likely be done with a with a cloud events binary HDP call But for everything else The the engineering work of that mapping is something that arguably AWS will have to do and and there are Server-side there are server-side work that needs to be done for everything That's a multi protocol service if you want to do mapping between Between one protocol to the other so that cannot be done without participation of AWS. I understand that for The AWS user community if the AWS user community wants to use past services and they want to use cloud events That there will have to be some description of how to go and use this and probably also formal formal specification And that is I don't know whether where the AWS use user community would go and do that Does the adapters stuff that we have help it all in this for example we have one for S3 are ready I think that's different because the adapters are events that are being raised about a About a service and it's state changes. It's not how events flow through a messaging conduit Gotcha. Okay so one of the one of the things one of the things that We certainly and now speaking for Microsoft. We certainly try to do here also is to make cloud events also a bit of a forcing function to entice a middleware vendors to pick up standardized Implementation neutral provide a vendor neutral protocol And not to reward proprietary protocol Mm-hmm. So Vlad, I'm not sure that answers your question, but is there anything else you want to bring up relative to it? No, it updated me on the status. I haven't Yeah It doesn't seem that they're interested. Do we have anybody from AWS now that team has left? I have not seen anybody from AWS since Tim left. No Okay, yeah We're we're having we're having our tentacles reach out in terms of some other standardization work and I don't think they're completely deaf to any of that stuff but AWS is certainly not as engaged as As the rest of the bunch are and so I mean in the end That's their fault But if if that comes up if I if I find an angle in a different discussion To raise that then I certainly will and anybody who does that with AWS should also do that Yeah, like I didn't ask them last week in a call because like we are customers I know like they are customer centric. So if lots of customer has the same thing they might do something Correct the loudest voice is that of the customer who brings money. Yes, I've heard similar things from them. Yes I'm still working in a company that we are 150 we're not like in the 10,000 So my voice is still just a whisper to them Yeah Okay, any other topics for the community time All right moving forward then so I got a note from the coupon North America folks or organizers Asking if we wanted to do a maintainer session for either cloud events or the service working group We don't necessarily have to decide on this call what we have until September 13th to take it back to them But we can do two different sessions because we have cloud events and service working group each one It's a 35-minute session up before speakers each If you are interested in participating in that please reach out to me and then we can figure out exactly who It's gonna do it what the topics would be and stuff like that I figure worst-case scenario if no one really volunteers like it's strong arm Clemens to redo the thing We already did for China and Europe Maybe I'm just giving the same video since it's not even tagged with what kook on it was for But I figure we should at least do something to update people if they're interested But if people have specific topics or if anybody else besides coming to myself Wants to talk please ping me offline and we can make it happen. I don't think Clemens and myself or Care that much whether we do it or not just somebody should do something is that the biggest thing I think Okay Any questions about that? All right, as I said, we do have an SDK call this week after this one We do have an agenda. So please take a look at that if you're interested teamwork isn't able to make the call today. He updated me offline nothing real Nothing really major to mention other than they're still working on the new logo But they are getting lots of interest from other folks Or look look into spec and they're they seem to be Potentially aligning us some collaborations with the projects, which is really kind of cool All right. So before we jump into the PRs anything I'm missing from the agenda before we jump into it All right Now the first one we actually approved last week But just let you guys know I haven't merged it yet because I have not been able to sync up with Kristoff He may be on vacation to find out if he's okay with removing that little bit of non-normative text that people had a problem with Once I I'm able to hunt him down. I will Talk to him about that one and if he's okay with it, we'll merge it without that change Let's see the first one on the list is Remy. I believe this one is yours Man, I want to refresh everybody's memory about this one since you introduced it last week Yeah, it's just when talking with you like it's just I realize that you don't always have the permission Close enough to the discovery service to be able to make it dynamic So we just losing the requirements Because the spec as it was designed before you will not list even that you don't have access to The discovery service, but the discovery service can basically aggregate several services without knowing their permission scheme So in that case he's not able to do it dynamically. So we'll just to fix that Okay Any questions Comments All right any objection then to approving? All right. Thank you everybody All right next one The wonderful id one So after last week's call, I believe the only thing that I changed in here is down in Um Where's it? Yeah, so down here in the api section I made it so that it's um The exact name. It's not a search term. So the name has to match it exactly a case and sensitive though um, and then I opened up an issue for us to revisit the topic of of how to do a Talk about a phrase a wildcard type search, right? So a partial name matching kind of thing Um, there was a at least one other suggestion mentioned that Since the service name has to be a uid. Maybe if we can do slash services slash Name and let that be the trigger to mean it's a It's a partial match thing. I figured I that's a big enough discussion That maybe we should pull that out to be a separate topic and let The id part of this one sort of pass or fail on its own and then If it passes we can discuss how to do the the partial search thing But I think that's the only thing I changed since last week aside from any typos I think Scott may have noticed at one point Any questions on this Give me all the talk we had on this one. I I don't want to jump right to any objection to approving because I don't know how people feel I know that there's there was some reservations but in my I don't know it's bias or not, but my bias opinion more people were in favor of doing it Even though there may have been some concerns about losing the the human readability form of having the name in the url I feel good about it That's what you wanted That's the kind of feedback I'm looking for. Thank you Anybody else want to speak up pro or in favor or against? Okay, any objection then to approving? Okay, and keep in mind nothing set in stone if we decide later on we actually really hate the idea we can pull it back out Okay, thank you everybody Next one pagination spec. So just to refresh everybody's memory I took an ai to go see what it would take to add paging type of functionality to our spec and I decided that We actually may want this type of functionality for other specs like perhaps for the schema registry or the I guess that'd be only the one scheme registry So I decided to create a separate specification that can be reused in conjunction with our other specs like discovery I pretty much based this on A lot of stuff I saw out there Like on github right where they use a camera the spec number Where is it? It wasn't 333. No, it's um Yeah, I think it might be this one rc 5988 it defines how to add htp header links that look like these To your htp responses to include exactly this type of information, you know things how to how to get the the next um The next chunk of responses or to get the previous ones um, I don't mandate anything in particular in terms of uh You know minimum sizes and stuff like that that I do to find a little bit of negotiation I did notice a typo here. Um, I did in the text. I removed the talk about Expires as being part of this this is actually a typo here The expires here should not be here rather instead um You know what this is old I'm sorry. I forgot to push this. I made a change to this section where I include an htp header for the expires based upon clemens's comment um I will fix that I apologize. So if you're looking at this Know that the expires is not a field on the link. It's actually separate htp header that tells you when this, uh This pagination stuff will expire and that's going to be useful in cases where someone actually wants to have a um Sort of a persistent state associated with their pagination query because maybe the data is changing on a regular basis and They don't they they can't return a static set You know for page or the static list for say page three is always fixed, right? It may be changing You know every minute kind of stuff And so they may need to keep some sort of persistence data associated with it And in which case that will include some sort of unique ID Somewhere in here that allows them to know which query this person's iterating over Anyway, I apologize. I thought I pushed this up, but I must not have for the expires header But with that any questions? Okay, given my goof up from not pushing the latest stuff I don't feel comfortable asking for you guys to merge it because you haven't seen the latest stuff So I will fix that But I guess I'd like to know from the group. Is this general direction. Okay. I mean, are there any concerns? about I think the concepts of what I'm putting forward here aside from my typos and the expires stuff that I forgot to push What do you think of stream support dug? stream support like if I Basically like an active watch on the services So instead of paginating you just stream out all the results as they change I personally don't have a problem with that. I if we do that I'd like to see that in addition to this because I think both are valid use cases, but if somebody wants to add a Streaming kind of thing as well. I guess we could look at doing that I don't have a personal problem with it Anybody else want to chime in on that? Sounds lovely to me Streaming of pagination stuff might go nicely with the proposed but postponed GraphQL bindings too So I'd say that one more time. You said this would go nicely with the GraphQL stuff Yeah, I think so Doesn't GraphQL have native pagination and support for that? I don't know. I was gonna ask you that I I've only looked at GraphQL very very briefly and I didn't I didn't notice whether they had pagination or not As far as I know, they do But I'm not fully confident. Yes, they do Okay So you're suggesting what are you suggesting about their pagination relative to ours? Or this I should say I'm very much in favor of this. Okay Did they follow a similar pattern to what we have here? I'll be honest and say that I have already seen enough to be able to comment on it. Okay. I'm just curious And obviously if people are okay with this and Are they okay with this today and then in you know a month or two they realize? Hey, this is wrong. We should do it the way they do it and to me to change it. We can obviously Okay Yes, I think there will be more discussions about the the like the parameters for example the page the page number thing Maybe some some people will disagree about using the this kind of pagination like because Like adding a new Record will change the page You know like if I add a new record to the beginning of the collection and the page might change from three to four which is Inconsistent Yeah, actually one of the changes that picked up from last week is I don't remember who this person is Sanjay They suggested using limit and offset instead of size and page which I actually did change and I again Apologize for not pushing it up there. So I don't know if that it that helps your concern at all I don't think it does but from just a naming perspective. I did go limit and offset instead But I think your overall question about you know, what happens if the next page or offset whatever you want to call it Changes because something was added or removed, right while you're in the middle of this pagination, right? Yes, that's exactly why I wanted to talk about that's exactly why I wanted to add that expires thing because If someone and on the server side if you want to actually support Not, you know, you want to support someone not getting messed up as they iterate over these things I want to get us in essence generate a static list and then When they're done pagination when they're done with the pagination, they want to in essence delete that temporary result set They need to know when when it's safe to delete it, right? And that's what the expires time is supposed to provide sort of that handshake back and forth to be able to do that kind of stuff um Yeah, some aps they use uh, like the next token kind of thing, which is the next token usually is the like uh, a primary key or something of the collection Back to the you know, the Name and id discussion like for example a name could be a good Next token like if I have 100 All the names, right? I can no matter how you add a new name to the beginning or the end I can always use my current the next token, which is the name to paginate to the next Next page Yeah, that that is true. I just wonder how you handle sort of edge cases where let's say you have a Instead of size in here, right? You say next token or next record, right? And you have the id um, what happens to that if that record vanishes If that that record is removed, I've seen yeah Oh, but that's fine. You know, it's it's uh, I can uh, usually we just need to make sure the uh, the Next time when I use this uh, key to query The next page Usually it's just the larger than this key. No, I'd say yeah Gotcha I can I can Comment on some some more details and examples Later, maybe yeah Does anybody else have any comments on that? Because I know there are lots of different ways to do this kind of stuff and I have no clue in terms of what's You know, really really popular out there You know, my only feedback is I like this. I think the scheme we're just talking about where instead of having page It's offset and so you could say offset 10 size 100 and you get uh, you know stuff from 11 to 110 so interesting So aside from the name change, do you actually view offset as Semantically different than page Right, so you offset is more like The tenth record out of a thousand where page to me was the third page out of 10 Right, but you have to you have to calculate the offset based on size times page Whereas offset if you just ask for offset, you you know that you're getting the 1000th thing in the collection, right? Interesting, okay. I'll have to go back and take a look at the text and see Because honestly when I when I made that change I did basically just a search and replace on the words I guess I need to go back and make sure that the wording Uh is more record based as opposed to page based Because there's because you're right. There are different semantics there, so I'll take a look at that So thanks for the reminder scott okay Any other comments? Does anybody have any strong objection with heading this this direction? That's my biggest concern right now Okay, not hearing any so then, um Hopefully next week we can look to to approve some version of this thing based upon the comments I get It's been out there for quite a while Okay In that case, um We have a whole bunch of work in progress things The sdk rules or maintainer rules, um, that's on the agenda for the sdk call So I don't want to say how to discuss that here. However, if you are interested in that topic Please join the sdk call. Um, because we're going to be talking about that one Um gem, um, unfortunately told me you cannot make the call today And I don't believe he's out on the updates to the protobufs specifications. I don't think that's going anywhere um Slinky What do you want to do with these two? Uh, I think what we should do is close both of them But keep the issue open Okay Any objection? Okay. Sorry. Go ahead. If the community is not interested in this moment In my opinion, the progress still persists. So That's why I'm saying we should keep the issue open and maybe those two are not good solutions I don't know but We don't necessarily have to close them. It's more from my perspective It's more if we're going to keep them open Then I'd like to see at least some forward progress being made like even if it's just offline discussions that are happening Um, but I got the sense that that there really aren't even offline discussions Um, and I don't know how to interpret that is it people don't like the solutions is it people don't think it's a problem People are just busy Okay, for example, Clemens you had some comments on the multi part mode one one Did you think that it's not a problem? Did you think that the existing specs already deal with this? Do you remember what the discussion was a while ago? Yeah, I Yeah, I believe I believe this Is uh, not a problem Okay, so I guess slinky for you the question here is do you want to have offline discussions to Either be convinced that Clemens is right or to convince Clemens that he's wrong or do you Not feel it's worth having a discussion and at all we should close close it In all honesty at this moment. I I really don't that time for this. So, okay, that's fair. It's really it's really time sucking so Okay, that's fair. So then like the proposal then if there's you go, it's right If there's only people that is interested then I might They'd get some time for this and continue but If I'm the only one I think people I mean that there is not even point to start to work on that. So I'm very interested. I just don't have a lot of time. We have a concrete use case around data ingestion on big data pipelines and Multi part or json streaming would be Exactly what they want to ingest cloud events into like a data lake But yeah, I don't I don't have time to dedicate to that solution right now So it's interesting Um Do you guys want to keep them open and just Let them sit in the backlog for a while or close them in the reopen Because we can I I don't mind going the way. I just wasn't sure if there was any interest in it because aside from From slinky sky. I think you're the first one who actually spoke up and said hey, this might be useful I I think um, we should take an action item Maybe table the discussion around closing these and everyone should go and talk to their data scientists and see if they're interested in cloud events And then what's preventing them from using it because I think it might be ingestion speed and if that's the case then A streaming proposal is probably better I was talking to my data scientist and he was saying that the reason cloud events is really interesting Is it cloud events allows you to have? Uh a single ingestion pipeline where the schema is self describing And they're they're really only talking about structured mode That's uh in my in my use case, uh, I wanted to to play with kinetic venting and try to To implement some kind of streaming between the different components. So At some point I used to To to experiment some kind of use case So a use case for that because Uh, again, it always connects to the fact that there are some payloads that are trimming by nature okay, so Okay, well, it sounds to me that we have a we have a proposal rather than to close it right now To give it at least one more week have people go off to the respective Companies or whatever to see if there's interest in this stuff And then maybe our next week's car revisited and see what kind of information we get back and make maybe make a decision next week Or at least revisit discussion next week. That's not fair. Yeah, specifically ask you like the big data folks that you work with and see if See if they're interested Okay cool Thank you everybody for that All right, um interop can discover respect. Um I apologize. I don't know if I was this if this was a formal action for me to look this at a time to discuss But I just noticed it again this morning as I was looking through the notes here. So I guess I'm proposing that Since we have an sdk call every other week. Maybe we should have an interop or implementation discussion about the discovery spec after next week's phone call Where you know, whenever that whenever this call ends, we'll just roll over and talk about interop or implementation details next week Everybody okay with that? Okay Oh Are there any other topics we want to bring up relative to the interop or implementation details though? I know personally. I haven't had a chance to do any more coding yet. Unfortunately. I hope to but I just ran out of time I don't have time either I suspect everybody's busy scott said the same thing Okay, I'm not hearing anybody jump in there Okay, so maybe by next week the phone call next week might be a forcing function for us to find some time maybe we'll see Okay, with that we're technically at the end of the agenda. Are there any other topics people would like to bring up? Conquy or hunk. Yes. Yeah. Yeah. So is there a place documenting how the The community and the vendors support the cloud events How they support it? Yeah. Yeah, or do we know which vendor? Is supporting the cloud events We know that there are some out there because we just hear about it Like for example may might give kudos again to Microsoft me in the first one formally supported in their in their bridge stuff But I don't think we have a formal list any place unless someone else on the call can think of someone who's been gathering this information Yeah, if there's a list, I'd like to happy to add Alibaba cloud to that list Actually, hold on a minute Hold on So we do have This So at a bare minimum we can add you to here Um But I guess we have to be a little careful though I don't like to get other people's opinions on this because this is meant to be I think open source stuff Um Yeah, do we want to include proprietary stuff here? It's pretty old Yeah, it is old It sounds interesting to to know a list of uh vendors you can go to that support cloud events Yeah, I agree a bit useful I I guess what we could do is rename this from open source to just usage or something like that Right and have an open source section as well as a proprietary section As long as we have more than one then I won't feel like it's straight to advertisement Right, um Then I won't feel as bad What do people think Some work too on the cloud events I'm sorry I said against Scott you're cutting out there a sec Google also supports cloud events on pub sub Right, so I mean, it's not just one. There's okay. Yeah, I yeah, I was just picking on microsoft. I didn't think they were the only one Was there someone else trying to speak up there? Yes, all right, um with the main cloud event .io website Is there a list of integrations and different vendors? I keep forgetting we have a website Here we go So yeah, we have this too Yeah, we can definitely add ally bobby here I don't I think the bar on on getting at it to here is just you poke somebody to do it Or open up a pr against our web repo um More here than in a markdown file in our repo like this is more visible. Yeah, I agree So why don't we do that if so I'll tell you what I'll I'll send out a note to the mailing list saying if you want to get You know your company or we're offering whatever it is Added to this page Open up a pr in our web repo and then ally bobby you guys can can do that as well. Is that sound fair? Yeah, yeah, yeah. Thank you grant for reminding us. We have a website That is a great place to put it so hold on Okay, here we go cool. Thank you any other topics we want to bring up All right in that case let's wrap up through the attendance list and then we'll jump over to sdk call Uh ginger you're still there I am Doug Hello and nick Nick what about daniel? I am here. Excellent and grant I heard you already. What about sam? Whoops. Oh my gosh what I do Sorry, Doug. I'm here. Who was that nick? Yes. Okay good and what about sam? Are you sam rue samry? Okay, did I miss anybody for attendance? All right with that Thank you all for joining if you're not interested in the sdk stuff you are free to go Otherwise, we'll start the sdk call up in about a minute or so Thank you everybody Vlad are you trying to cause trouble? I haven't had time to review all the videos from the time I missed. I'm curious Go out of your way make trouble. It's I would never I'm an angel. Yeah. Yeah. Yeah My goodness gracious All right, um All right, let's get this show started here. All right slinky. You have an announcement to make I believe Oh, yeah, so after one or two months Uh, I finally managed to release the sdk rust version two version zero point two Uh, huge thanks to a new guy in the community, which is helping quite a lot with Uh device features, uh, if you open Can you open? So among the new features really important now we have the kafka integration So there is the integration with raster de kafka, which is the most important library to use kafka rust So you can do things like sending or receiving cloud events with kafka And then we did a lot of improvements on the apis to send the receive hb request Um We have new apis uh on the event. We have Reducing the event builder and then there are improvements in doc and stuff like that. So yeah, go and check it out Congratulations, it's exciting any questions comments. All right next one So Go away zoom Okay, so we have this pr out here which to find some rules for How to add new maintainers and we are trying to or the the original idea was to put this at the community level that way every single Uh sdk didn't have their own special rules However, it appears that there isn't not a whole lot of discussion going on around this and it's not clear whether that means people are Okay with the proposal or people don't like it, but they're afraid to speak up or having a time to review it How what are people think about this? We need to decide what we're going to do with this puppy I'm okay either way. That's uh I have not I I don't have a strong opinion in either direction. Maybe that's uh, that's explaining why I'm silent on this So does that mean that you do not think we need to have any formal guidelines? Um newcomers to the group can read Uh, I think we should have them, but I'm not I'm not and I'm okay with these rules Uh, but I have no strong opinion of whether they should be at the sdk level or at the You know at the overall community level. I would be okay with the latter, but I can could understand individual um sdk Subteams would want to have their own their own rules okay, so I said not not a super strong not a super strong opinion either way in that way in that regard But I think the rules are required overall Okay, thank you comments daniel Yeah, I just got a chance to read this for the first time this morning. Um, I think And it looks reasonable. Um, I uh, my My sense is that a lot of us Just don't have enough experience maintaining these particular Uh repos to to have a good sense of well is 20 the right number or you know, what what what what's the right level? and I think there's some some just Uncertainty around that since and given that you know these these My my sense is my guess is that this is not set in stone That you know, we could start with this at the at the community level and then as Uh, each of the sdk's Proceeds and and we run into specific situations where we have to make a decision Uh, maybe uh, maybe it works and that and maybe it doesn't work and then at that point we have more information to make Uh refinements, uh, even sdk specific refinements So yeah, I'm I'm I'm fine with starting with this All right, cool. Thank you. Scott your hands up I agree with what daniel just said that what it occurred to me that we are part of the cncf Maybe we can ask the cncf for advice here for these these repos and the guidelines In my understanding the cncf kind of stays out of this kind of stuff. Um I I I agree with what daniel said. I actually like the idea of saying Uh start with this and then adjust as we go along The the only concern I have is Whether all of the individual sdk's Are okay with with basically buying into These rules right because if we approve this then it's at the global level Which means every sdk is going to need to adhere to it and I think the concern that I was hearing was You know the the people that have been involved in this like lance and obviously slinky They're okay with it in general. Um, but is that sufficient to then force it up on all the other sdk's when they haven't spoken up And so this is more of a forcing function to get people to speak up here Yeah, that was a good point I think personally, I'm not in favor of Of enforcing or are writing down rules with Maintenance, I mean ideally someone can Come and go, um For some languages like php. There's there's probably not going to be Someone creating 20 prs before becoming a maintainer um, and I don't know if everybody's going to read all of this, um sdk governance before creating prs and Not sure that they need to but Um, if there's a possibility to maybe slim this down, I think that might be a bit Fair as well Okay, I have a question for you, but Scott your hands up first Yeah, I think I think, um This isn't really for contributors. It's for actual like the maintainer rule for the repos so People coming casually to update Random bugs and stuff seems fine But if you actually want to have the keys to the castle then It's nice to have some guide some guideline to understand how to get there if you're interested Yeah, I think I think that's the the bigger concern is what we don't write down how people Or if we don't write down what the path is to become a maintainer Some people will look at us as is not a real either a real project or oh, what's a secret club kind of thing And we don't want either one of those views, right? Uh Yeah, that makes more sense. So yes, yeah for a background. Yeah okay, um Okay, actually that kind of answered my question. Lance your hands up Yeah, I mean, I you know, I've said it in the in the pr itself, but I I am just a little concerned that putting Hard numbers down Is going to be problematic for some repositories. I mean It it may be that 20 is a a pretty large number And it might be discouraging. Um So I what I said in my comments in the pr was that maybe there could be some sort of softer language around what it is so that the each sdk has some leeway in making decisions that aren't necessarily hard and fast based on um, you know actual numbers, um Yeah, that's uh, I guess all I really have to say Would would you be okay with language that's something that's that's something like, you know, they've made a significant number of reviews and put something in For instance, it says significant is obviously subjective and will vary based upon the repo, but You know, at least then they know it's not just one Right. Yeah, yeah, for sure. Okay. Let's link it your hands up Yeah, so I think we can Make things more specific than for each repo like like I say at line 26 They say eligible for request. That's something that really depends on the language like Again in java typo is three files change With 20 lines per file Well, in other language, it may be some it's shorter. So I think then we can maybe make these requirements a little bit more art on each repo But the reason why I prefer having other requirements in general It's that you make things more transparent. So if you Use software requirements my I'm worried that this could make And it could make decisions less transparent Okay, that's that that's that's really my concern about having software requirements But again, these we can maybe relax the requirements in This document and then on each repo we make the requirements more strict depending on the language depending on the library depending on the project itself Okay So I think in the document here, there are two different sets of numbers. There are things like, you know, where is it? Like 20 reviews there are those types of hard numbers And then there are other sets of numbers like at least two-thirds of the votes Based on what I'm hearing here. Is it fair to say that people are okay with Things like two-thirds of the voters have to agree that those numbers are okay It's just whether we want to loosen these numbers like the 20 reviews kind of thing. Is that fair to say? That two-thirds of the vote for the maintenance of this decay not for all the maintenance Yeah, I'm just worried about that. Yeah, I was losing with my wording there But in terms of numbers, I assume it's these numbers down here. Okay It's this number up here that you were concerned about. Is that right? No, yeah, that makes sense. Okay. So when we why don't we do this Um, I I'm not hearing anybody say no to to doing the rules. Um So what if we do this? What if we say We'll give people one more week to offer up alternative language We'll put a message out into the stk slack channels to warn people that Um They need to speak up by next week because if we don't hear any major objections to doing this and You know, whatever minor tweaks to the wording we make between now and then Hopefully they'll be they'll be done relatively quickly But we're gonna approve this thing next week and be warned. This will be at the community level, which means it will apply to all stks And so they need to review it and and And it's what's what's the term people use? Um lazy consensus kind of thing So they better speak up So it's a it's a warning shot across the bow to pay attention That's good. Let's do it. Okay. Any objection to that? Okay, cool bureaucracy behind us. All right grant. This is all you buddy. So y'all let you talk to this stuff Yeah, sure So, yeah, um want to first give the professive, um I think some of these issues have been solved. Um For context I've been Wishing to use some developing Some packages and samples for javascript using cloud events And I've been wishing to use the cloud events stk rather than just manually parsing uh htp headers and and body and and creating typescript types so there's been some great progress and um and I guess uh, I I'm I'm sort of looking for uh A solution in terms of like Um towards the end of last month, uh, I was like, um Recording a demo for using the uh, new SDK and There was like an error with receiving cloud events and and validation which, uh basically um crashed the program, um Never trying to receive cloud events and And I was sort of curious like why do we even validate when receiving cloud events, um When a developer just wants to accept their object and um And so I guess I I wrote down um A rambling or or or just some issues things on my mind of um, what I sort of expected in terms of the the developer Experience and and the progress that we've made um As I've said many times there's been some making amazing progress with the javascript uh SDK um but Like there's some issues that um Where I can't use the SDK at google for some of the google cloud samples, uh To some issues, um I just I guess I can go one by one. Um first This was the main issue. I saw like the SDK over over validated the cloud event where um Yeah, as I said, uh through an error for like a valid cloud event and and I'm not sure exactly if if the SDK Should verify a cloud event is Is valid or not when just trying to consume it? um second issue is um There's just there's some things that have been improved over time. Um about just Providing a more idiomatic common node experience of being able to consume And sending cloud events and I do ideally like One line to code where you don't need to create new objects for emitters. Um, all of that's been been fixed, um Still still, uh I think there's some still some other issues that we could fix um, and I guess overall like I sort of wanted Wanted to understand maybe how we can better test uh rs dks or or I don't know if it's Just the sdk. It's probably not. Um like Can we provide some example cloud events and And I know there's a conformance testing repo. Uh, maybe we can like Integrate that somehow. Um, and so yeah, I guess, uh So I was a little bit frustrated with So like the impact was I I recorded a demo and You couldn't use this sdk unfortunately. Um And So I mean all in all I I'm really just looking for, um Like what what can I do to to help improve the situation? um Been I've been more involved with With some of the code process, but I I feel like it's it's not like the amount of Code changes doesn't really matter if um I guess the end experience Isn't isn't it's uh ideal So so that was the long longs of rant um And really I'm I'm just Trying to figure out What what I can do to help Make the javascript experience Which is Which is like the largest serverless experience, um at least for google cloud To be better Anybody want to chime in So okay So grant let me ask a sort of a naive or simplistic question here For the things that you've noticed um Does the current process of just either opening up issues or or or even better pull requests Is that Process broken in some way. I I guess I was gonna kind of confuse when you when you put together this list because my first reaction was to be quite blunt It's like, okay, there are issues. Let's get some prs generated, right? Yeah, um I mean great like creating issues and create um examples And then sending prs that's worked out um I'm not sure exactly what the issue is. I mean I serve I understand that this SDK came from a pretty bad state and we slowly morphed it into a much better state Um, but I guess compared to other SDKs. There's I mean, this is just one metric but there's um Like over 600 commits And I don't know how many prs, but probably most of them There's like 150 prs or something 100 prs and um I feel like just that probably I don't know if we're just churning through through Changes in code that doesn't really impact the end user Or what but I've seen other SDKs where It's been like less than 10 prs and you provide sort of an idiomatic experience Daniel your hands up um, yeah, so So ruby was used as uh as a comparison point and I I as sort of ruby maintainer. I do have to mention that Uh, you know when when ruby was developed Uh, you know, we're already We were already standing on the shoulders of giants so to speak. I mean the the the JavaScript SDK, you know, we JavaScript SDK and the pipeline SDK those were our starting points Uh, and so if And we were doing a you know, a kind of a clean room, you know start from scratch implementation from that um So yes, of course, you know, we have kind of a much more clean Uh, you know experience when we don't have that long history of You know churn in the the spec and Users and bugs and you know all that stuff that makes software development so interesting so So yes, I I think that's the You know the comparisons that we we see are are just to be expected based on the The the the states of the the various SDKs in there in their life cycles um I think that's you know, I I I get the The frustration here You know, I I I also work at google in the same The same role as as grandsons and so I'm I'm using these These libraries myself and I'm I'm customer zero as we say internally as well and and have And have to deal with these bugs And I and yeah, I think it's just harder when there's a larger SDK with more more history and a number of different developers who have worked on it to to To deal with the but we just have to kind of Uh, make sure that we raise them raise the issues as they come get them fixed and you know, it's it's just that that's how software works so Yeah, so grand are there issues open for all the all the things that you've identified um Yeah, I've been um to fleet creating issues Uh And As I think is mentioned. Um, yeah and some of the lengths like some of these Are resolved pretty quickly. Um I guess the main The main issue Is that I I shouldn't be like developing A demo or testing in production and then finding an issue and and the SDK Are in the in the I guess the The experience of using it. I know there's a lot of tests for javascript sdk, but somehow I don't know. I think there were like 100 something tests, but then something for like receiving a cloud event like It's like somehow the test passed, but the actual developer experience failed. So, um So yeah, I mean I can You can still like log issues, but I feel like there's just Going to be more issues that That won't show up until It's too late. So I guess I'm I'm confused as to what you're looking for right because I mean, I yeah, ideally um I mean, I One thing that I'm looking for is I'd hope I mean, I know that Like Daniel said a lot of a lot of the Change has been incremental and um I I guess what I'm I'm looking for is I I'd love to sort of like finalize I guess the the javascript sdk and move on to other languages and um And not sort of have months where we're constantly improving the sdk and we sort of just And I guess I think part of that is like There's uh Like I'd really like to like focus on the core use cases of Of the cloud events sdk rather than Um, I know there's some extra features of like discoverability and um I'm not sure what other ones but But so but but let me understand here so um So I think what you're saying is You based upon your experience with sdk. There are some things that are lacking and that's You know always going to be true every piece of software um um But in order to address the things that you're seeing I I really only see two paths forward right because You can't just snap your fingers and say okay tomorrow what everything's going to be perfect Right and we can move on to another sdk or another language, right? So in order to get to that that happy state that you want to get to it seems like There's two different things that need to happen Uh, they're not obviously music exclusive But one is open up issues for the things that you find and then the other one is obviously Open prs to fix the things that you find and I'm not sure What else usually you're looking for aside from those things To happen and whether it happens by you or somebody else You know it it seems like one of those two things needs to happen Over to get to that happy state that you want so i'm confused as to what beyond that you're looking for Or is it just you want those things to happen sooner rather than later? I mean, I just I guess I I don't want to spend as much time as I have been with The javascript sk and and not and still see that Well, I don't know this is probably a meta point, but just still not see the The developer experience that I'd expect And and some of these issues still arise Right, okay, right, but that but that's basically another way of saying it's it's not where you think it needs to be and that may or may not be true I I don't know but let's assume for a minute. It is true What What can we do to or what can you do to fix that right? Because it seems to me as a maintainer of the of the sdk The best way to fix that would be to open prs Right because you have you have very specific use cases in mind like for example You said you did a demo right and so therefore you have very specific flows that you have in mind that you want to get solved and It seems to me that if those flows don't work for you then You either open an issue or you open a pr to fix it to give you the user experience you want Right, I feel like I'm missing something here. Yeah um Yeah It's a good point. Uh, I'm not really sure of the solution um are Are exactly how to pinpoint the issue like and I that maybe one thing would be there should be Maybe I should create an issue like there should be better conformance testing such that we can provide 20 cloud events and test those and I'm not sure may like Not sure why why the existing tests didn't Catch this maybe maybe it's just improving the tests or Sorry, it's not like the original issue was that you were sending innovative cloud events and the sdk was rejecting it Is that not true because they do run conformance tests I get uh The the issue I ran upon when recording the demo was uh sending a valid cloud event And it was marked as invalid and And it didn't allow me to use the sdk Ah, this was from the unreleased code that was in master not the released code that's on uh node or npm No, I believe as as the release code under the cloud events package You know like I mean this isn't production Stuff yet We're all trying to work on this and try to get to a common place and the reason we're doing it in cloud events Revo is so that all of these vendors go and participate and we're trying to make this very generic solution that fits the needs of A lot of use cases like one of the balancing acts of being one of the sdk maintainers Is that you have to think about features for Specific use cases, but don't exclude the myriad of other use cases In in my day-to-day stuff. I only think about kubernetes, but there's not a single kubernetes thing inside of the golang sdk so I think some of my feedback for you grant is that your bugs are They seem to be very focused on the exact task you're trying to do and I think You're getting pushback because that might not be the best Direction for the sdk because it's a generic solution not a specific solution Yeah, that's Go ahead. Sorry grant. Yeah, I was sorry. I mean, uh one thing Like I I do know that the issues that I've raised Are from examples uh with With one vendor and and one uh couple like styles of um cloud events but um, I mean, I'm not sure I I'm not sure exactly why um, how like just sending A cloud event over hdp that would different would be a different requirement Or or how that would be specialized for my use case I know there's lots of other different protocols um But I guess Yeah Okay, wait did Daniel your hands up Yeah, so I think what I'm hearing here is that there is uh uh some There's a sense that uh, you know a particular sdk is really not production ready. It's it's you know, they're they're They're issues with it and there isn't a uh There there isn't a well-defined path and a well-defined metric for saying, okay, this thing is this this is ready now for You know all the general use cases that we that we expect from like a ga level piece of software And so maybe I'm Conformist tests have been Mentioned before and I think maybe we we need to kind of define. Okay, so What what does it mean for one of these to be kind of Quote-unquote 1.0 ready or quote-unquote, you know general general availability Of that quality where And then kind of have a have a comprehensive set of tests have a And then and then you know have a way to to measure. Okay, so you know And and then we can Then then we can Number one test against that and then have a have a goal And you know to be able to better communicate these these types of These types of concerns. So oh this isn't working for my my case Well, is your case in the conformist test? Is it part of the spec is you know It's something missing from the spec and you kind of have those those kinds of conversations because that's that sounds like what we're We're saying here. We have a a particular experience That was Was not you know was not great And well, how what is that? How does that Translate into what do we do about what do we do about it in the SDK? Well, we can fix bugs here and there, but does that satisfy the the experience And so how you know bridging that That that got kind of the abstract experience for for a developer doing a demo and then how Meetin potatoes, what do we do about it in the SDK? So, yeah, maybe Maybe having a Conformance test or some metric for this saying, okay, this is this is how a General but no GA quality is defined for our SDKs. Is that some Grants that make sense for was that capture what you're saying? um a little bit, I mean as as um Lance mentioned in chat like we do run, um The conformance tests And so I'm less familiar with the conformance test. Maybe I should be more familiar with that um I think I think the existing conformance tests are there's just like a couple of tests And so it hasn't been really fleshed out to the extent that it could be Uh as far as I understand it. Yeah, totally. It needs more And that was the intent is that we get the bones in people using it add more tests than then Everything that's conformed testing for free One question I wanted to ask I think Doug dugger I forget exactly who said this said said this. Um So in terms of being like production ready Uh, I guess my intention Or my goal would be to use this SDK in a production library is that Is that not something I I should have as a goal in terms of like are these should these SDKs not be as reliable as something you'd run in production I would assume all the SDK authors want their their set to be used in production. Sure Okay But it's it but it says, you know, it's a process, right? And if they're not there today, then we need to work on a path to get them there And the best way to do that is to identify the gaps and and to open up prs and And to help you help get it there. But I guess I guess I'm just still struggling With what you're looking to get out of this conversation I mean because you you you you expressed your Your concern you you think that the SDK isn't where you need to be Okay, but I'm not hearing a path or suggestion for you to get there Beyond what I think is already our Our normal process, which is issues prs And I but I but I feel like there's something else running around in your head that I just haven't been able to grasp yet That you're looking for something different besides that I mean That's the way I've been rolling um In terms of creating issues and in prs not as much as um I mean lance or or other contributors um in One idea is just I guess one thing is I'd like to understand um there's been uh We've mentioned like uh every but every Every person has their own use cases. Um And That might be an issue in terms of understanding uh the different use cases I've been I've definitely uh Sort of created issues and prs for Like the htp receiving use case um I guess like one idea is just creating List of different use cases so that I can understand how other use cases uh fit in um I didn't I feel like this I guess the frustration is like I feel like the The process of building this sdk should be simpler And not as time consuming And part of that maybe is well, I need to understand these other use cases And I'd hope that the process would be this less time consuming and and we could more or less have a final state at some point Where we can then move on to other things Okay, uh slinky your hands up Yeah, uh what I'm struggling And I think Doug you already said that what I'm struggling to understand from this conversation is What is for you and sdk production ready because that that's that's what I really do not understand I mean That's not a requirement that is written on the stone for any sdk out there I mean somebody might come here tomorrow and say go long sdk is not production ready But it's it's not enough. I mean if you have some ideas on these cases Why don't you try to write this down in the document saying I want to For me the sdk production ready means adding feature x y z Covering use case x y z and so on so then you can maybe start working on understanding What are the changes needed to to implement those in sdk itself? I think that's a reasonable way to do that and Yeah, I mean, you know sort of along those lines. It sounds like grant may be a bit useful if you could document Sort of your vision for what a production ready sdk looks like what its features are What is the user experience and stuff like that? because if nothing else it will It would force a discussion among the group to see if everybody agrees with that vision And hopefully they do and if they do then that's going to lead to You know either concrete issues or even better concrete poor requests to take a step in that direction I'm just I'm trying to figure out some you know sort of concrete next steps here to To address your concerns That's the only thing I could think of offhand Right doc I think that's the best solution but but I I guess the the one thing that I that You said something interesting though grand in your last statement you said something about You know, it's taking a long time or the hearing the exact wording, right? It's a it's a very time consuming process and I don't think anybody would disagree with you. I mean, that's why most of the folks in these sdk's they seem to spend Fair portions of their day working on these sdk's and I know a lot of them actually have other jobs as well um but I'm not sure how to I'm not sure how anybody can address that Concern of yours unless you think that people are focusing on the wrong things Because if you assume that they're focusing on the right things in the sdk, it's just taking a while because there are so many things that need to get done There's nothing that can happen there other than You know help find people to actually work on it Um, but are you suggesting that you think people are focusing on the wrong things? um I mean, it's been a process as we've discussed of envisioning but um changing the library I in some ways like I'd say yes, like there's Well, again, I don't I don't know exactly the use cases it'd be great to maybe see that from folks and how they're using the sdk and I mean in terms of like I think it would be good to give an example. Um So at one point I wrote an alternative to the the javascript sdk Which was like the typescript sdk um, and we sort of went with that and of course that was like a very slimmed down mvp of um an sdk that fulfilled the requirements of being able to consume a cloud event and provide like um an object and had served the ideal developer experience and And I guess the amount of time that it took for that was like a week or two um and I guess I would ideally I'd like to have a have a developer cycle allow allow changes in sdk to be faster sort of similar to that I don't know if I'm going anywhere I think we've had a lot of good discussion. Um Yeah, I mean continuing the issue and pr uh cycle Sounds okay Okay, I guess it might but I do think it'd be useful though if if you could Uh write down in some fashion your your vision for where you where you think you'd like things to be and even if it's as simple as These are some of the features that you think are missing whether it's features that are you know Functional features that are missing or user experience type features, you know just to you know Oh, this should be this way because the current way you can do it Isn't as user-friendly as it should be right if you can at least enumerate the things that you think are missing that Keep it from reaching that that happy state that you want to get to Being able to jot those down in some fashion be really useful. I would think Yeah, I can definitely do that. Um And I think that'd be useful for a lot of sdk's Yeah, I'll go and That's a great suggestion. I'll I'll go do that for Um my perspective for job script Okay Is anybody else want to chime in here in terms of any possible suggestions for next steps I sort of want to um, I don't know if Lance is on the call like on I sort of want to understand, um some of the yeast cases and really just anybody on the call of um, some of the yeast cases for cloud events sdk, um that Maybe I'm missing Are just in general Well, yeah, I'm I'm on the call. Um We're using the cloud events sdk in a project. I'm working on at red hat for fazz on knative and Using it in another project that I can't really talk about um the The I think one of the things that Came up as a potentially contentious issue and I guess it was on a github issue was exposing Not just this object called receiver, but also exposing a binary receiver and a structured receiver and I think it might have been scott that commented on that and and put it pretty well. It's you know, there are There's a sort of the really simple use case that I think you're looking for Um, but there but that use case isn't the only one and it might be that you know in in a certain System, uh, we know that all of the events are going to be structured for example So why go through in order to optimize our code? Why go through a more abstract sort of just receiver thing and Instead actually use this thing. That's a little bit more specific. Um, you know the structured receiver So I guess that's maybe an example of how Just exposing only very simple top-level interfaces Isn't going to work for everybody Yeah, that's a good example on some thoughts. Okay, that'd be great. Um, thanks for listening. Sure. Uh Okay, any other Topics Yeah, okay any other topics you want to bring up for the call today Okay, I guess that's it then lunch time All right. Thanks everybody. We'll talk next time. Thanks. Okay. Bye