 Got it. Okay. Thank you very much. All right. Let's go ahead and get started. It's three after All right, AI's AI's I don't have anything urgent. We're going through there unless someone can think of some of they want to mention Okay, that's not community time. Are there any community related topics people like to bring up? All right, not hearing any SDK update. We did not have a meeting Last week or this week yet, so I'm sure there's anything new there Austin I see you've joined the call. Thank you. Is there anything you'd like to bring up from the SDK perspective? Nothing. I haven't I haven't been involved in those meetings as of late. So I'm a little out of date That's fine All right. Anybody else from the SDK sub team want to mention anything? All right Kathy, I don't see her on the call. I don't think anything happened there with workflow So demo proposal that's got the forward we did I don't think the workflow meetings are still happening. So does it make sense to still have this as a thing that we talk through every time? I can definitely remove it. I Don't apologize. I actually I think I took an action item to get with Kathy off on to figure out what we're gonna do there because There's it doesn't seem to be a whole lot of forward motion Yeah, I think that I think that like they came to a good place and they presented it And I don't think it's like an ongoing thing. Yeah Okay, well, I can if we remove it and wait for Kathy to mention it as a potential topic. Is there any objection to removing it? Okay, hold on Thank you, Rachel Next demo. So I think we did a dual poll and we agreed on Monday at 1 p.m. Eastern for a call to talk about The next demo and that's to go over the proposal. That's a couple forward It's gonna be using the same zoom as the record phone calls. So feel free to join if you can If not, obviously, please comment in the document itself Scott, is there anything you'd like to mention relative to that? Just want to give you an opportunity to speak up if you want But no, I don't I don't think there's anything extra from that proposal. It's still open for you know, modifications and New ideas. So please come to the meeting and come with ideas. Yep All right, cool. Any questions on that one or for Scott? I just want to like if you haven't looked through it Scott, do you want to give like a two Senate summary of it for everybody else? Yeah, sure It's so the the general idea is that we will simulate What real people make for businesses? And hopefully it's like cobbled together and duct taped But the the general idea is that there are a couple of roles that people can fulfill There's the producer or like a factory role Situation yeah, it's like an e-commerce factory see so there's the factory services that send over cloud events to the warehouse inventory service and those get like added to the inventory and then the There's a store UI. Hopefully and then people can buy stuff through that UI it gets Reserved the inventory and then sent to a delivery service where like maybe some fake updates get sent back to a delivery UI So it's simulating kind of like maybe what would happen like on a Etsy or an Amazon where there's independent creators that adds stuff to an inventory and then you can consume things out of that inventory and Then you could simulate being a FedEx like thing In the middle there, okay, that sounds Interesting and more interesting I would say than like all tweeting something which was good for the first version Yeah, and so potentially like one of the factories could be Like a cookie clicker UI like thing where you actually tell the audience Hey go to this URL and like click on my cookie and then every click turns into a cloud event that goes to the warehouse That adds to the UI so that people can like consume a cookie on the other side Is my cookie the joke is that the like your vine like a physical cookie. Yeah I shouldn't make sure this wasn't like Like a browser cookie. Okay. No, no, no, no, not a real cookie like there was a game or like the cow clicker Right, it's just like a busy task that you they do right they sit on their phone They click the thing and like maybe we have a display of the seat showing the active inventory counts. Anyway, it's I'm trying to make it interactive. It may or may not work. The conference Wi-Fi is kind of spotty But they take in the audience involved is always usually pretty good assuming it works well Exactly, I think thanks for indulging me and explain it. Sure. Always good to refresh. So thank you All right, any any questions for Scott before we move on Okay, yep, so please join the call at 1 p.m. Eastern on Monday if you can EU planning so we have the two sessions we talked about the intro and deep dive We have a call right after this one to discuss, you know, what we're gonna talk about what we're gonna present Who's gonna do presenting stuff like that? Obviously, if you're one of these people, please join the call If but you're obviously free to join if you're not one of those folks just to hear what's going on or if you have ideas And it's gonna be the same zoom channel as this one All right, moving forward. Are there any questions on that? All right, cool. In that case, let's get to the real work here PR review Chris Yeah, hold on to me So this This one technically it's a little bit on the new side It was put in there two days ago I think it's so maybe okay to bring in but I thought because it's more of a type of more than anything else I wanted to get it out there sooner rather than later Yeah, I made a couple of weeks or months ago made a change Where I renamed your eye to your eye reference Because this is only the placeholder that we use in the spec. It already said this is a your eye reference But the shorthand we used was your eye And that was pretty confusing. So I renamed that so one of the mistakes I did if you scroll down to the spec markdown is that I missed the schema URL So I forgot to rename that as well. So this pull request mostly changes that Then I also found that here in the bottom on the constraints. It said it must adhere to the format specified in RFC Which is a bit duplicate or confusing Which everywhere you want to look at it because the UI reference is a subset of that RFC and it's not so clear So I just removed that part and if you want to know what exactly the string should look like you can go to the type definition of the UI reference I Changed that in the spec JSON as well five you introduced this last time and then in the protobuf I also changed the shorthand Because I think the protobuf PR that kind of go in parallel with mine. Yeah, so I think this one was just a miss Yeah, that's a miss as well. And then this is duplicate and this one is okay the URA references a valid format for JSON schema. Yeah, we already have it in the source actually got it Okay And instead of removing the RFC reference in the spec should we just add the section as well? Sorry, I didn't get the question So in in in the spec that MD you're removing the section that list the RFC However, in the in the other form, it's being more specific about which subsection Should we just add that subsection to this as well? I Try to be Consistent so if you look at the full spec markdown file Okay, so in the full spec we have in the type system Defined what a uri reference is so here we have the full link and then if you look Further down inside for example the schema Add the source. Sorry the source We only say it's a uri reference and then in the constraints. We don't put anything extra So I wanted to be consistent with the source Got it. Well, we yeah Well, we can change it, but I'm we should change it in both places I don't really mind either way Well as long as a more specific reference is in the document already then I'm fine with it Yeah, I think it was yeah. Yeah, I was okay All right. Any other questions? Anybody need more time to review this one? No, it looks good. All right. Thank you, Rachel Any objection to approving them? All right. Thank you guys very much and now we have Rachel You want to bring us back up to speed on what this one's about and then where we are review-wise Review-wise, I don't think it's gotten any comments this week unless someone added them really recently I don't think so. I think the last one was from Chris stuff And then I think you added something saying anyone want to comment or something Yeah, the other guy's from the rocket mq stuff. Yeah I like my overall perspective on this is like I'm open to having a higher bar for people that would like to Add their proprietary spec Like my motivating factor is that I want the spec to be adopted and if adding a place for proprietary specs Further's adoption. I think it's great. I think I feel like it costs us almost nothing and if we like I'm not incredibly concerned about doing free advertising for people because if I were looking for A protocol and I went looking inside of our spec for like what should I use? I feel like I feel like you're not really making sound technological decisions at that point. So Good luck to you But If people have different perspectives, I'm very open hearing them and like making this proposal into something that everyone can get behind Like my main like my like the proposal here like the comment here Raises the bar considerably like it. Uh, it says that you must prove like you have to be able to prove that like if a cloud event gets sent into your system, it should be able to come back out of your system and The thing that I think about that is like we are not really in a place to validate that like they could they Like we're not going to spin up their like protocol and like test that is true like try try using it for example, so I'm tempted to use an honor system here and just assume that people are being um Good faith actors if people are more cynical than I am which I'm very open to uh, then we can We can try to like brainstorm on what at like a What balances we want people to be able to like embrace the spec no matter what technology they're using with um Also being cynical about what people will say about their specs So I'm really open to comment if people like my basis if no one else leaves comments I might say like I might try to pull in some of this wording here into my spec, but I'm not inclined to like um To raise the bar too much more because I want people to just like say we support this spec I went I want people to like be able to like ascent To it pretty easily. I want that bar to be low All right anybody want to comment either uh, you know, christoph or uh, clements. I know she came off mute anybody Want to comment? Yeah, I'm I'm a little bit more cynical about this and I'm also um A little bit worried about real-world politics that are potentially being played here and Also, we're trying to be mindful of those um so Occasionally it appears that some folks who are building stuff That is not necessarily aiming to interoperate with anybody are trying to gain the systems that are the open source organizations And the standards bodies And without arguing with you, could I just ask for an example because I'm not I'll be concrete because it's right in here, right? So rocket in queue It's being submitted as an incubator project into the patchy If you look at the if you look at the actual contribution it comes from one place And then shortly and then shortly thereafter. I don't know exactly what the what the uh, uh, the order is open messaging Starts to exist in the Linux foundation coming from the same place And except for a benchmarking project Also has no contributors outside of that place Wait, so just because one company is doing most of the development work doesn't mean that something is not open See and there's and there's the question for me If there is if if if it's one if it's one company doing all that stuff with effectively no outside attraction And it's only really being used in one place And it's specifically and you see that it's it's using A proprietary protocol that's not even documented. That's it literally the protocol is the code right and then and then there is an open alternative That you know a a broad number of company have companies have been investing in And are currently investing in With a you know common protocol stack that has quite a bit of attraction And that stands against that and then we're doing an interop project and and effectively The game that's being played is obviously trying to wedge that proprietary product into something that is looking like open even though Nobody's supporting that open thing except themselves Okay And I'm sensing and I just asked what's in the opinion then I'm I'm I'm sensing that The system is being played and I'm not sure that I don't understand what the system is being played means though Like we can say like they're playing a game or they're playing politics But like I don't understand what the end result is so like is corporate capture open source Totally a thing totally. It's absolutely a thing. That's definitely a thing. It makes for crappy open source I'm as guilty of it as anybody. I totally agree. That's a thing But like I don't understand what like they're playing the game like what game are they playing They're open sourcing something and they're putting the work in and like They're all being washing they're open washing something like the open specifically open messages back has lifted text literally from the cloud of it Right, are you upset that they liked your words and they took them like I like That's the hard it's so I'm I'm upset. I'm upset about someone trying to play a you know intro via API story That is exactly opposed to intro up on the wire, which we're trying to achieve here and and then and then effectively and using uh writing a check to legitimize that by by having a project created for them that then says open Well, effectively It's a proprietary play what have they gained. Okay. That's something that's and that's a game That I think I see that as a game that's being played on the open source and open standards community Um, and so that's the thing that I'm worried about here So that's that you asked me for an example. That's the example I'm bringing you for and I still don't totally understand It's not necessary that I understand honestly So I can like I can drop it but like just to let you know why I'm still skeptical about this It's that like so if so say I'm I'm putting myself in their place, right? I like I have built this thing and now I want to open source it and um Like is anyone else using it? No, but I'm still really excited about it and I want to put it out there like I have I have like gained Very little like by by like getting it I like I don't understand like how they are winning something right like they have put in They have invested in this thing and they've put it out there for others to use What do they get out of it because like I would be skeptical if like They were like secretly getting tons of like hidden benefits, but they're not Like they are they've just like put something out there in the world that will sit on github And maybe no one will use which is like a thing that can happen I don't feel that bad about it, but they can claim openness right and they can claim compliance because They we allow their proprietary protocol Which is only implemented in their product and cannot be implemented anywhere else because there is no protocol spec to be bound by An official binding into cloud events. And so they are now a cloud event compliant even though Nobody else can talk to them And so that's so that's something that I find that fighting than weird and that's that's what I have a problem with that It's also the thing what Christophia says is there's got to be an implementation in that product That literally interoperates and if it doesn't then it's the question of you know, what are we doing here? So that's that's my the question is not should there be a product that interoperates It's like who is responsible for figuring out if it interoperates and I want to say that's not our job I want to say like if you claim to interoperate then you're responsible for actually interoperating and like we're not like We don't have to validate that So let me go to the speaker key. We do have a couple other hands up. Jim. You may have been first. So go ahead Hey, thanks. Um I I understand Clemens concerns. I I guess when And rachel, thank you so much because I think you sort of picked up one of my crazy ideas with this um I sort of looked to this originally more in terms of well, where would IBM, you know, if they wanted to do a Cloud event transport binding for mq Where would they put that and it to me it just seemed That wouldn't be something that this group necessarily would write because it's not an open standard um, but we would want a place in our In our environment or community to to sort of house that binding so people could understand how it should work And and I think that was my original sort of desire when when this thing came up not to necessarily link it to purely open source initiatives It Clemens does that do do you understand where I was coming from with that? Can I Yes, yes, I yes, I understand. Um I would expect so frankly, I would expect the mq team to um Bind to cloud events via either um, mq light, which means their mqp head Or their mqgt head Or their or their htp htp head, but not using one of their four proprietary mq port Okay, but wouldn't this be the place where they would? explain that Yeah, but however they end up so if the question is The question for me is do we need to have do So we can have a catalog of of products that support cloud events and we can point into in in that catalog We can point to the respective product documentation. I think that's that would be totally fair But that's a proper spec. We really only need if if the spec can really be implemented by another party and for the four, um Different protocols that are in a q for private area um For those four There is no product. There's a there's no there's no spec and and we have to know that because that's also We have a license to one of their protocols And it's literally the only way you can go and do this is by reverse engineering and listening to the stuff on the wire because The documentation at IBM is the code for it So that the situation for that is exactly the same as with rocket mq You can't write a protocol spec for it because there is no protocol spec to reference So I think my hands up next So question for you clements. I'm trying to stir up my head around this and see try to see both sides or understand both sides um I'm wondering clements if if your concern is more focused on whether someone can then run around and claim That we are endorsing them in some way or Yeah, like I'm in the sense that it's not so much. Oh Such such protocol is saying. Hey, we're cloud event compliant or we're you know, we we we support cloud events I don't I don't get the sense That's what you're worried about you're worried about someone coming back and saying that because their document is now on our repo We as an organization or group have somehow deemed them as worthy and that they're going to somehow profit from that in some way Is that accurate to say it? Yes, that's one part and the second part the second part is Since I see this group also as an advocate for interoperability I don't I would find it sad if we if we would reward products That even though There is effectively an industry a recognized industry standard for doing a particular thing for instance how to Create interoperability around the message broker um that nevertheless ignore that And use their proprietary product and we reward them effectively with you know interoperability award at a level that is Like at the protocol level that's unreachable unless you have interoperability one level below So so basically endorsing their proprietary choices And for me interoperability means if you literally can go and plug and play things together um And and not you know claim interoperability at a level in the protocol stack where Factually interoperability is not possible. So i'm i'm just looking at this from probably a pretty religious uh interoperability stands um of You know having inter interoperability interoperability down the stack right tcp And then overlay the the framing protocol may that be htp or mk2 tr8 or air compute and an overlay on top of that sits cloud events with the respective encodings etc But but i believe interoperability from the ground up and not having you know in interop in Non interoperable thing where that sits in the middle that prevents that you can even benefit from cloud events So it sounds like you're saying if if we don't necessarily host their documents here But we have maybe a list of of pointers To documents host at other places and say oh by the way Here are some other formats or here are some transport bindings or whatever that That do support cloud events and we make no claim as to whether good bad or anything And it's just a list you'd be more okay with that it sounds like Yeah, absolutely Interesting so i'm not i don't want to exclude i don't want to exclude anybody from getting a pointer it's just i'm i'm worried about the the the effects of of You know having is a proper stack in the in the in the repo right in the repo on On what we're trying to achieve the perfect interoperability Got it. Okay. Uh christoff your handsome Yeah, i think i'm a bit less religious than uh clements i'm i'm more from a practical perspective so the thing like i I don't know about rocket mq or open messaging or whatever like if a customer comes to me and says i want to Integrate you the platform that we're building rocket mq. I'm generally in support of that And my sort of dream is that i have an implementation for cloud events there is Maybe something in between that they have to set up like an sdk or whatever But that basically it's plug and play. Maybe I have to plug something in the middle, but then they can just implement Well, they can take our platform. We have we emit cloud events and somehow they end up in rocket mq But if you just allow people to drop a spec and then don't do the work of providing the adapter or providing a standard interface Then if we just have like 10 20 protocols and in the end We can't send cloud events from one system to the next so that that is kind of my fear Hi, this is john. I'm on the phone Yeah, go ahead. John Thanks So Yeah, I think I think I follow along that. I think my concern is a big enterprise Right is I I have to deal with companies all day long saying that they support xyz protocols back standard whatever and The biggest part of that part of my job is verifying how they're all lying sacks of shit Right because it's it's marketing hype. So so I guess part of my rabbit support on the clemen side of the sense is the You know, what are our rules around people being able to use part events? Uh logos trademarks Stamps of approval certification To be able to make those kinds of claims that are going to confuse and market play Right interoperability is obviously a critical piece for a lot of people right so You know, where where is that going to fall? So Where do we where do we draw those kinds of lines? And what's the seal of approval? right for interop Cross usage versus hey, we have an adapter that allows us to You know hook these things together in this more proprietary hodgepodge way and maybe that solves problems for certain users But it solves it in a way that is not Generic enough Right to be to claim true interop Does that make sense? I think it does and somebody else has anybody's cell hand up. So let me ask this question of rachel um For the goals that you're trying to achieve rachel How important is it that you that they actually host their documents in our repo as opposed to Is it okay? Can I can I address some of the things that were said before? Okay, I I'm totally sympathetic to not wanting to give out awards for openness or interoperability for someone that is Just writing a shim over their proprietary thing. I don't want to do that. I don't see this as giving an award or Saying you are interoperability like champion of the year Here's the thing though Like we are all running proprietary products that we charge money for and that we think offer a unique value and the thing that And like we've still come together saying that like we agree that interoperability is valuable despite that Despite like it being like we we are all running proprietary things here and like the difference Between the things that are going in the main spec and the things that I see going in the proprietary protocols like uh folder I like the difference is that one set is owned like the Like the direction of the spec is open and uh anyone can join that conversation that they want to The difference is not that like we're not charging for our products, right? So I like I don't like I don't see this as A stamp of approval. I see this as a way to gain adoption And and the the important the reason it's important that they go in the spec Is that I want people like it's a place to standardize it. It's a place to say like Are you interested in cloud events? Are you running any of these technologies? Here's where you go to look to see like what the like what the standard like serialization is Like that's The important part of it like it's a it's a place to go look That's why that's why I want it to go here if we like if it makes um Like maybe the right thing to do is to add wording about not being able to use logos not being able to like claim um Not being able to make certain claims and we can like work on the wording for like what the what it should be there if we If that's important So that like that's where that's where I come down like I like I really think that it is a greater risk for the spec That no one ever gives a shit now that we're gonna use that word. I'm gonna use it too Like it's a it's a greater risk that no one ever gives a shit about this than it is that um, that it's perfect and wonderful and uh, like like I just I just see like being perfect is Not my goal here like getting adoption and make like what's the point of interoperability if no one ever uses it Like where I'm coming down So as you put out a A pseudo proposal in there of is there an appropriate wording we can come up with to uh, to say You know you're spec being present in this repo or someplace in our org Does not give you the right to claim compliance use our logo or anything like that. What do people think about hitting that direction? Does that help at all clements? For ruin since you came off mute. You want to speak? um Sorry Oh, he went back on mute. Go ahead. Yeah, I I I didn't catch what you were saying. That's catch what rachel was saying That will answer rachel then. Okay me Yeah, I'd be interested to see what you're responsive um Yeah, so this the so for me that the higher the highest order a bit is driving interoperability and and For me interoperability is the thing that that ought to be driving the adoption like the desire to have um a a common stack that has uh A minimal amount of options, but the options that are appropriate for use cases and then go and use those Rather than you know adoption of this specification at all costs Because I don't know. I don't know how much that helps us if we Have you know cloud events being used within a totally closed ecosystem um where those events Basically can't leave that ecosystem ever because that doesn't help anybody Okay, so I agree with that like I agree like I want I I want to drive interoperability and I guess our disagreement is like How that happens and like my my assumption like so say I have say I have like my current stack and I want And I like the idea of interoperability um The like the first way I'm going to get started using this Is I'm going to like write a shim that like converts like at the like at the edge I just convert the thing like I don't change any of my internals and I and I Like write a shim at the edge that like converts whatever I'm doing to a cloud of it, right? And this is absolutely And this proprietary Like protocol and encoding like folder Is the place where they can do that for what you just said for that shim right for that shim for writing that shim So they can talk to a different product for that can need to have a specification Because you're now sitting down and you're taking all the internal loop that you have which might not even be in cloud events Compliant cloud events format You're changing that around And then now you are handing that off to someone else who speaks cloud events in one of three protocols Or one of four protocols And that's why we need to have the internet specs for how you do your thing inside of your your product and Even how the products how the events flow and how you store the events internally because we certainly in our product We don't store it cloud events as cloud events, but we have to perform it internally There's nobody's business But really what can't what matters is that your shim you sit down You have a set of specs that you can go and write against and then hopefully The result of that if that's compliant can go and go and talk to everybody And that's what I think that's what the spec set should should should do for us And and and how ibm would realize Cloud events inside of mq and even inside of the federation of mqq managers and how how rocket mq does that And how how service bus and and and our stuff does that internally between modes in the federation Doesn't matter because ultimately what we care about is the handoff points between one product and the next product in one system That the next and the next system that's the stuff that we that we need to agree on in terms of Interoperability, okay, and I just want to like I agree with all that and the thing that I just want to add is like The only like the only specs that should start using this should not be ones that are owned by the linux foundation, right? Like any like any protocol that people are using Like should have a way To like start using cloud events like you shouldn't have to like you shouldn't have to change What you're doing you should just be able to like start layering on the cloud events. That's like that's like what i'm pushing for Yeah, and and and I think I think where i'm at and that's this this agreement I think to make to to make the complexity matrix of integration and we have some people with it with enterprise integration background here Is you can't make the complexity matrix lie like you can't have 50 protocols to choose from and then everybody is is is You know one is feeding this protocol and the other one is is is pulling from this protocol um because then Then you're really not compliant to anybody because then you know you need to have the matching products which happen to speak those two protocols And that's why you narrow the choice down and you say here's three protocols pick one of the three and um And then and that makes integration more real But if you support 50 50 different protocols the choice the likelihood that you find two products Which actually speak both because it becomes slimmer and that's my that's my the core of my concern Okay, I think we're probably at our time box But um, I would really I'm interested in getting this like I am happy to compromise on this pr But I'm like the thing that I would most like is to get a version of this like with whatever caveats we need Like like if I have a proprietary protocol, I want to be able to say Here is how I'm supporting cloud events. And if you want to do it too, here's how like that's what I want Yeah, I was going to suggest that some sort of trying to find that middle ground position is maybe clements But if also if you'd add a comment in here To state what you would feel comfortable with with some sort of what your proposal would be for what to do with these things Unless your position is it sounds like his position is I don't want it though Well, yeah, I'm just wondering is clement. Is there a middle ground position where you could have something that you could live with I think a catalog of implementations, which um, you know support support cloud events. I think that's okay I'm just I'm I am I just I would like the spec set And what looks like technical documents to be constrained to those which which drive interoperability across products um And so let me yeah, I'll let me comment on let me comment on this and then basically summarize summarize my my stance here I don't yeah I Care about us going together to plug this You know and then go and and write some code That allows us to plug things together And then we should not have to go and pick up 50 different adapters to make sure that You know one can talk to the other because we're not building integration products We're building regular Damn software and we should constrain ourselves to a few choices so that we don't get stopped No, we would be constraining everybody though Like we're saying like if you want to support cloud events get on one of these like three or four bandwagon Like use our thing no matter what you're using like just start using it now and that's the way to get to get adoption That's it. Yeah, you see that as I said, that's the difference. I don't want like a option at all costs I wouldn't have adoption of interoperability Okay, so let We're slightly over time. So let's do this Clemens if you could put a Comment or proposal or something in there to because right now it appears Rachel's a proposal And then we have the other the other side is basically saying do nothing And I actually think there may be something in the middle there. So maybe if you could Write what your view of a middle of ground position would be and we get some discussion going and maybe Circle around the real answer at some point Can I can I also ask like I'm like Clemens and I are dominating the conversation but I would also like if you just like have an opinion on this and Like I would appreciate knowing like what the temperature of the room is So if you feel so moved by the spirit, I would love for you to like add a comment on the pr or just like I don't know Let me know somehow because like if I'm like out on the deep end. Let me know that like that's what I'm That's what I think. Yes. Thank you for that reminder. Yes, please give a comment in the issue itself Since we're over time All right, so I think we beat that one pretty well Christoph, would you like to talk to where we are on your minimum size pr? Okay, I won't go through the whole background of it Um, basically last time we ended up saying or we were discussing if we should have a hard must Or basically ended up in two places. What should the actual size be and then The other one should we have a must or should because we we discovered some cases where maybe a must is too harsh Let's say we have an iot or an edge device that doesn't have enough bandwidth or memory or is constrained in some other way I then proposed a third option which is say well, basically For me the point is Some people will will write a middleware and some people will write the end consumers What I want is that all middleware sort of work on a consistent way and and if someone as an end consumer goes and and Drop something. It's maybe their own thought that they can't consume events, but the bad part is sort of I write a A good consumer in the end There's another good producer in the front, but some of the middleware that is plugged in between just randomly drops events That's not Uh, that's kind of what I want to prevent here Um, so that's why I proposed the third option that says, okay, you must support it except When you are a consumer That is heavily restrained So basically everyone who writes a middleware that runs in the cloud has to accept these limits Um, but if you're a consumer and you happen to have these constraints, then you don't Okay, that's where we ended up. Yeah, okay, and there were some comments Put into the pr since then we had one person vote for your new option Uh, a couple people I think remember four or so voted for option two We just changed the most to a should and Kathy it seemed like she can go with either the first or the second Anybody wants to chime in on the call now to add their opinion Mark I was wanting the plus ones for should Okay, it relax a little bit Okay, that definitely seemed of the limited people that did voice an opinion. That definitely is leading the way has it right now Anyway, I just wanted to say anything Okay, I'll I'll speak up here. Um personally, I I would prefer option two as well only because I think The third option is it's fine other than I think you get the same results with the should Or strongly recommended actually if I prefer it, but either way um I I don't like the idea of a must with an out because that to me means well Why not just make it a should or strongly recommended? But that was just my take on it Anyway, I also have an opinion Okay, so how would you guys look like to move forward on this? We don't have um 100 agreement do we want to Put this up for some sort of vote and let that decide it or how would you guys like to work on this? Keep passing through discussing it Kathy you're coming off me But Kristoff We may change because you know, once we put a size there, I think you know, um If we put a size that can be applied to more use cases or more Compone, I mean more even consumers. I think it'll be good people are trying to It means sure people would like to be compliant with that size So Kathy, I don't know if it was just my connection up, but you cut out a little there in the beginning Are you suggesting that we do one and two or or? Yeah, yes, I think you know, um, yeah I think if we can give it a smaller size and then put sure I think more People will Will really do this Be compliant Okay, so you're just in one and two. Okay Uh, Kristoff, are you gonna say something in there? Um, I'm okay to uh compromise on a should or strongly recommend the only thing I really want to have is that Uh, sort of everyone in this group then agrees to honor that limit So basically then I would also want to pick the 64 kilobytes if uh clements or event grid basically Wants to keep that limit on their side Then we should have that limit sort of that everyone in the group agrees to support With the products that we built you I would be very happy if that was the case. Yes I would still like you should rules The clements just refresh on the 64k is within the limit for you guys, right? Yeah, 64k is our limit And and and based on as I said based on principle and not necessarily on architecture only but also principle Okay, so I'm hearing a couple people now saying we should do both. Um 64k and should I know you asked for one more week and whatever we're not voting this week But is there anything else you'd like to say jim since you did kind of speak up there? Uh, no, I don't anything I have anything to add to this one. Sorry. Okay. What are the what do people think in general? What are they just like that general direction of 64k and loosen the must to a should? Hi, this is Vladimir. I think we can go with should I'm I can I can be convinced that should work fine. Thank you. Okay. Thank you lemur anybody else Okay, what I think I'm basically hearing is do cat the suggestion of lower the limit and go with a should And so what I'm wondering is maybe what we should do is Ask kristoff to modify the pr based upon that And then see if we can vote Um next week on it. What do you guys think about that direction? I'm gonna take silence as Consent Okay, kristoff. Are you okay with that? Yes, let's do it. Okay. I know one of your big concerns just to get a number in there and that would be 64 Okay, so Um, okay, so you'll get that on there Yeah Okay revisit Maybe vote I should say because we don't know for sure Yeah, what feels reaction to it is All right, cool. Um, okay, let's go back to the claim check one Anything happened since last week on this one Not really we quickly presented it last week Clemens made a comment which I can maybe read Walk through it. If anyone likes that Um, yeah, what was what was clements comment? Or is it in the pr itself? No, it was in the call um Basically the comment was um, why do we need a data ref? um people Why should this be like a top level thing on the spec? If you want to point to something you can also just embed it in the data itself Is that correct clements? Yeah, I didn't find this I didn't find it necessary because you couldn't have in the data obviously you could point to multiple different objects that are external Um instead of just one So this seems like this seems like a very specialized case of having exactly one uri inside of data Well, that is not if I may respond that is not the intention the attention is You have a data object Which then in turn may contain other ui references or your eyes, but Here is like the main outer data object does not fit within your message And then you're instead putting it into the data ref. So Then if you catch that so you can kind of replace both either you have the data You can also take it away and replace with the data ref and then another part can come in Um load the data ref into it or go what is behind the data ref and replace the data ref with the data again Yeah, I think I think my my my point is it is um It is just as easy to go and put a uri into data uri object into data Then having a first-class construct for this like It doesn't necessarily make a lot of a lot of severity is easier to force everybody to implement that implement that pattern So come in Come on this one Um Now let me go to the speaker key first. Uh gem your hands up I I'm just uh, I think one of the other things that clements had touched on last time was the fact that You know just having a reference to something Could be potentially dangerous if you don't know The size of the thing you're pointing out or maybe what it is. Yeah, so I I understood that concern I again, you know, this seems to be double whammy for me because I I think I was one of the original instigators for this as well um Again, my intention here was to say if this is something that a lot of people are going to Dream up by themselves because we set this limit of 64k or whatever it is. Whatever we finally agree on Shouldn't we prescribe a method where people can Um, you know Work around that limit if they have to and so that was really again My only drive was to say let's just show people a way to do it Rather than eat everybody coming up with their every implementation Coming up with their own way to do it. Um, so it was more of a um a design pattern Which was then codified All right, that's actually why I raised my hand was oh Clemens a question for you Let's say we decide not to have the attribute and we tell people to stick a ur around outside the data field Wouldn't we still need some something in the spec that tells people exactly how it should How it should work or how it should look to ensure that we have interoperability So exactly so we don't get what jim is saying, which is everybody does it their own way basically I would explain the claim check pattern in the in the In the guidance But when we need to when we need to format or specify what the format should look like if you choose to stick it in the data field I mean, is it is it simply that there's no wrap around it? Or is there a url wrap around it? You know things like that so one of the So a reference to an external reference to a lot to a large object you would you would point to um Could be could be manifold right it could be it could be that you're pointing to um a large Graph that sits in some in some document database if you want to go in reference In where you speak a particular protocol to get at it Let's say you're pointing to a record in mongrel database And it's impossible to go and set the entire record of the mongrel database with all the dependent dependencies with it So you basically point to it or you have a large file Or you have a video or you have I mean there's all kinds of documents you can have It needs to go and further qualify them and how you qualify them and probably how you give further hints Like the size of the documents etc might differ based on the kind of document that you have so i'm i'm I have a fit. I also have like it was said a fidelity concern around that link In terms of how much metadata you further need to make sense out of that out of that reference And and that This might not be the only this might not be the only link that's sufficient to go and express that Basically giving uh a client that received them and received an event uh a choice of um of what they might of of what they might want like say Let's say you have a an image database and you store a new picture right and you send them an event Um the event is about the picture and they ultimately want want to have the picture But maybe in the data you want to give them a choice of getting a thumbnail or the original resolution Or a choice of thumbnails and so all of a sudden you're pointing to Four versions of the same or 10 versions of the same picture While it's theoretically a client check pattern Because you're not sending the image but you're sending a pointer to it You're actually sending a very qualified set of of links That you then further declare with uh and this image resolution for with the set But it's it's applications specific Okay, so that's that's kind of where I'm coming from because that's The principle that we have in general in in our product is to always point to stuff and never and rarely carry the stuff So we'll always have these references in line in the in the data and then leave it to the application to do an interpret Interpreting recording and here this seems like the most rudimentary case specialized Okay, uh christoph your hands up Yeah, um Let me as a I think that this thumbnail example doesn't really Well, it would be a misuse of this your eye reference. That's not what I would like to use it for That is my point. So, um, I think they are There are valid use cases. So, um, for example, aws For sqs, they have a limit what they have built in their at least in a java SDK away for that you in the java SDK Can say I'm sending this message And then someone else With the same SDK can consume can consume this message So if you're sending a message below that limit, it will be put directly into sqs If you're sending a message above that limit, it will actually put into s3 and then the pointer to that s3 object is put into the message and then The sdk on the other side will pull out that data from the S3 blob storage So the good thing is as a both as a producer and as a consumer You really don't know if that happens in the background or not So that is I think something that That is worth considering having I'm not sure how many people run into this political issue For me that is In in my daily work. This is often a case where I really don't Or let's put it this way. I already point to the object itself by having that source But what I'm sending in a message is often a change set And that it can be very small or it can be very big even for the same event type. So, um That's kind of the issue that I have and then I dynamically want to make a difference Whether I'm embedding the data or they have to fetch us somewhere else and if if it would be like If my consumers don't have to care about it, that's good for them, I think Okay, I think Kathy you're going to have the last word on this for this week. Go ahead, Kathy Yeah, I think you know, I think this this, um, this PR is talking about out of band data, right not in band So I I think, you know, it's a good thing to have that because if you want to send a either large Large set of data you want to not to send an inbound or Restriction does not allow you to send an inbound. So it's good to have a data reference But whether we have, you know, one uri or several that's another thing we can discuss I think, you know, there are use cases that, you know, this definition will will help a lot Okay, thank you, Kathy. So there are a lot of interesting ideas they mentioned in particular Kathy and Clemens you guys have some some interesting thoughts on this. Maybe you guys could add some comments to the PR to get some discussion going offline Um Yes, sir, and we can see what how that how that plays out next week Let's see quickly just last 30 seconds or so I heard Kathy Sanya are you there? What about ginger? Yes, I'm here. All right, Sanya. Are you still there? Uh, no, Sanya to leave. What about Alex? Okay, is there anybody I missed for roll call? Okay, thank you guys very much and please do take time to comment on those outstanding PRs. Um And with that you guys are free to go except for the people who would like to potentially Present at the next coupon So those guys please stay on the call. I want to just give people a second to Hi, um, thank you Hi Yes, it is that Is what what? Uh, I was I was just I I was sure I had something in this time slot that it's literally just session with amazing Isn't that the way that works out? It's it's been a blur today. So I hear you I might be kind of grumpy. I'm missing lunch. I'm getting really really snippy and hungry Yeah, oops Let's see Okay I'm not a happy camper when I don't get to eat Where am I going? demo demo demo Let's see. We still have whoops. Okay. So who should be here? Let's see. We know clements is here. Scott's here Kristoff's still here Vlad's still here Chad is wasn't on the call Dan's still here. Okay. Everybody who's supposed to be here is here. Good. So we can get started All right Mr. Scott, if you don't mind, I'm gonna lean on you to drive more of this discussion since this baby is your idea In terms of how you want to proceed. No, no, this is the demo I'm sorry. What are we talking about? Oh gosh darn it I'm mixing up things. Um, okay You're right. Turn it. Okay. So in that case Presentations, okay, so um Oh darn it I'm gonna go find you a granola baller. Hi. Yeah, exactly. I blame it on the hunger. So actually I'm turning over if there was um There are a couple of comments I could have sworn I put oh, yeah, maybe send the invite because people didn't make comments on ideas for what to talk about And I know I put them somewhere and I think I put them in the Yeah, I think there is a dock. I remember well, no, there's not a dock here. I found it Uh, I'll move this later. So hold on a minute. There we go. So these are the ideas that I've mentioned so far Okay so um Let's focus on the intro first I think based upon the description of the way of the way intro calls are supposed to or the intro sessions are supposed to be We have to at least give the generic one that we give almost every time Which is what is cloud events? Why are we here? Why do we matter that kind of stuff? Uh, it does not necessarily have to be a very long session But I do think we have to at least give that brief intro for people who don't know what the heck it is But after that we're then free to fill the time with whatever we want So as a follow-on for intro session, do you get what would you guys like to see the next topic or set of topics be? Uh, maybe like the hello world of uh How to use it like how to send an event? Okay Mm-hmm So this is Is this would this be like a hands-on here's how you use it or you're just a demo of seeing an action What are you thinking there? I mean, yeah, maybe like actually draft out a uh, like a simple application using one of the sdks Okay, live sdk usage Okay Whoops can't type All right anything else. Yeah, I think I think for this for this particular where we are For the I'm a big fan of of of showing Um plenty of code Um Well, so so spend more time in the sdks and and if already there some product integration scenarios More than then talk about theory because we care about The you know people adopting it before that Having code showing code is good and and for me the the those conferences Seem to be ones where code showing code and demos is very appreciated Um more than than you know dry architectural conceptual talk. Yeah code and demos and like tips from experienced people in this In the generic intro is there a uh like here was the world before cloud events And this is what we're trying to make it better Yeah, I think I think that's that's that's that should be in there like where what did come from why do we exist? and And here's the here's the thing we have kind of a brief overview and then from there it should really be And this is what we can do now Yeah, is there like a a big like final wow like Today, this is super hard without cloud events, but here's what we just did There's this crazy thing that we just connected Uh, I don't think we have that yet, but that might be a good idea if we could think of one. Yeah, yeah Yeah, we don't we don't have the the how terrible the world was before Oh, I might have something to present on this, but I don't know if it'll be ready before then like we um The company currently working with Is that I implement the whole pipeline for automated deployments And the whole internal dev tools will be using cloud events The main driver for this is the fact that we have to send the trace IDs around and we have to use SNS sqs and stuff like that And there's no easy way to use Tracing with that and cloud events seems like it's going to be a good fit I had exactly zero time to test it that I'm super annoyed by that Okay, well am I correct in assuming that that would fall under sort of These live demos or descriptions of how we're actually how people are actually using it today in in rural world scenarios, right? Yeah Yeah, again hoping that it'll be ready, but I don't know Okay, it sounds like we have a good start in terms of what we might be able to talk about at an intro session And I think we only have 35 minutes. So between these things we should be able to fill up the 20 minutes 25 minutes or so after maybe a 10 minute highlight of who we are So let's quickly switch over then to the deep dive session Uh, what are you guys thinking about from there? Yeah, I think another hello world at this time actually show extensions and what you could do with that For example, like the trace ID is cool Hold on God, I can't type The tracing in the deployment pipeline I just spoke about Is planned to be implemented with extensions. So it might be better to move it here or get more in depth Here, I don't I don't know Okay And again, all of this is very much theoretical right now You're doing this today with Istio Yeah, there's there's there's a good news on that front. Um, by the way that in the w3c open tracing spec Is that what it's called? Yeah, I think so That's been that's been referenced from there That is not also getting an empty t and a An mqp binding so we can go online only on htp what we can also align on the The the mqp binding Neat Yeah, I know that because I had to review it Okay, so I'm trying to think Is a deep dive Is there anything we could do there aside from just showing it being used? There might be some gotchas Like with some of the you know Here's we can now support protobuf, but like well, it's you know, not really ideal So that goes back to sort of lessons learned or um A deeper lesson learn talk, right? Yeah. Yeah, I guess that's that's tips and like here's here's where the the edges of cloud events exist Yeah There's there's the don't use this don't use this to do A general messaging Aspect there as well, right? There's like patterns into anti patterns and I think I can The anti pattern section is pretty long Because you can bet that people will come and make the reply to extension and I really really really really shouldn't Like things you should not do please I think we should add that just to torment your comments Do not do that So if we if we go ahead christoph sorry, yeah, I'm not sure um We assume that the people who are there probably don't use it yet and may have only heard the intro does it really make sense to Go and talk to like, okay This is the stuff that doesn't work and you know more focus on on the positive examples of what it can be used for And uh, you should do this this this But then they don't really have an idea and they had what they should do with it Yeah, I think you you've mixed the both both you you do both things maybe that it sounds like We should do a quick intro of like what is eventing? And where where cloud events fits in my technical perspective and then perhaps Maybe we can show performance of cloud events for different protocols That is that is enormously difficult because you're really not showing cloud events per Well quick question. Yeah, I was just trying to think of like technical things that you could show in a deep dive Yeah So let me just just for the note-taking purposes scott when you said what is eventing and where it fits Do you see that as a deep dive thing or is an intro thing? I kind of think it's a maybe a little bit of both Yeah, I think that should be covered in the intro Okay So we'll think okay. We'll cross that out, but even maybe for that then performance is that That that's what scares me um meaning because I it comes awfully close to potentially slamming someone some thing some product Yeah, I'd be cautious of that is probably it it might be subjective Or not as objective as we might want You okay if we drop that scud that scares me a little. Yeah, sure. That's fine. Okay Okay, what are the things we do for deep dive? I mean we only have 35 minutes and glad's thing Or whatever we come up with whether it's a lot or something else could take a quite a while so that could be I may not have as much time as we think I mean is this are these two hallow topics good enough for a deep dive? What is the demo fit in here? Excellent question. I forgot all about that so I'm kind of wondering whether we do a little tease the demo in the intro And then perhaps do a deeper dive discussion about the demo I'm wondering whether the demo could tie into some of the lessons learned in some way Hmm You have to learn those lessons first Well Trying to implement the real-world scenario that you're having your demo may expose some of some lessons I would hope Yeah That's actually it isn't this in question though I don't know what you guys think where we do want to do the demo I don't think we have another time slot to do it at the conference itself. We've done we've done the demo in the intro Um in the last time I think the demo in in the intro makes more sense To at least show well, it depends what the demo will be but kind of showing the demo off in the in the intro Is a good cliffhanger for the deep dive session Um because everybody wants to see code and so you'll show the demo there and say well If you want to know how we put this together then it'll go and come to Yeah, maybe the the actual code moves to the deep dive Like we show the demo we we dive down but but you start with uh like here's the hello world using one of the sdk This is how easy it is and then from this we built the the demo you you saw in the intro and we can show it again Okay, well, it seems to me that a lot of this decision also may be uh based upon How the demo actually looks and feels and how much time it takes to actually run through it, right? Because if the demo takes 15 minutes to run through that's very different than You can show it in five minutes. Okay. Yeah, that may influence. Yeah So maybe we should hold off and leave it as a place holder in both spots To figure out where it goes once we feel like the demo's flushed out more. How's that? Yeah, I I agree and I agree with the other points That might belong in both depending on the complexity Okay, okay um I feel like we have a fairly good starting point for an outline What do you guys want to do in terms of next steps here? Go off think about this but I put this into a document Ask you guys to then comment offline to Try to expand upon the thoughts more. We can talk about it now. We have 45 minutes Unless you guys want to go eat I have one more one more question and then I can go get pizza or some um This is very cloud events focused and at the last qcon in europe. I really like how there was Also chat, how are you using cloud events? What issues do you have and journal talking about this kind of stuff? Would it be worth to have Something like this to why I would just get where the community is with and see if we need any other working groups or stuff like that I'm not sure I followed that I used I used to sing a sort of discussion with the audience members to find out What their view is of cloud events and where we want to take it? I'm right Sorry, I got lost cloud events and how they're using serverless and what issues they're hitting Like more generic serverless work group Stuff, I guess I don't know Again, that's that's like a bird's like a bird's of a feather type thing. Yeah Okay interesting now I I think you're planning on having a serverless Day, I can't really that term they use for it. Um I'm wondering If it if it's better to to save that discussion for for that thing or Take up part of our time in cloud events because it's a bit of a shame that well, actually let me back up We originally Were given the option of having a deep an intro and a deep dive for both cloud events and serverless because technically it's two separate groups Do we want to change our mind and and not have just Do we can have four sessions I have enough people like a demo of serverless platforms or on kubernetes So there might be interest. I don't know We can vote I would think there'd be interest from the audience. I'm given How popular serverless is right now? Yeah So do you guys want me to go back and ask for Two sessions or just one for serverless? Maybe one of the long ones That's an idea Yeah, that might be an option. It might be good to have an intro for serverless even. Um, I don't know Uh, how much people will understand all of it? Um, or just laying out um, kind of what uh, what it looks like from a CNCF perspective And a kubernetes perspective Okay Okay, I can go off and ask and see if it's too late Because then you have a lot. I think that cover that we could talk about your topics in there I'm sorry. Go ahead Christoph Do we as a work group sort of Have enough content or will we refresh the white paper? I mean, I like the idea in general, but um I don't see how it lines up with what we currently do Interesting question. I I kind of view this as Sort of follow on For the working for the serverless working group itself to say, okay. Look, we put up this white paper We could talk about where we see the state of serverless in general and you know, talk about all the various um serverless products that set on top of kubernetes You know open fuzz k native all those things and then Sort of turned into like a birds of a feather kind of thing that someone mentioned And just get the audience engaged and say, okay, where do you guys think serverless should go? What do you think the service working group should? Tackle another topic, right because because in the past we talked about, you know What's the next thing be and we picked workflow? But that's not getting a whole lot of traction So maybe there's just something else we should be focusing on and maybe we need input from the broader community So we're not just talking to ourselves I don't know that was my initial thought when when you guys started hitting on this path Well, that sounds good to me. Yeah, yeah, that makes sense I agree If I can remember what I just said, okay, I'll write that down Someone get a good sandwich Oh Okay, um, so you want a bird of a feather? Okay, what do you what else you guys while I'm typing what you guys What do you buy? What do you want to do next? For that, I think that the white paper has to be revisited and so the landscapes changed pretty dramatically in last year Serverless has gone pretty big Amazon's released a lot of new stuff and there's k native and A lot of the frameworks have rebased stuff other technologies now Okay, yeah keeping that document current would be useful It's true So should we do an update for This session isn't to prep for this session Yeah I think that's probably the ethical thing to do Yeah, I agree Okay But it's a lot of work It is it is and I'm not doing it Such a definitive statement there comments, geez well, you know I just I'm just looking at my on my backlog and I don't want to raise any expectations that I could Okay, um Anything else? Okay, so tell you what, um Let me take all this information stick it into a doc we can noodle on it back and forth in there um I will reach out to Dan con to find out if we could if it's too late to get one long session for the service working group um Do you guys want to meet again next week same time same place? sure Come on come in say yes. Yeah. Yeah. Yeah. Yeah. No There was some But it should work One second. Where's the we are we are meeting on monday? Yeah, but that's to talk about The demo, right? Yeah Uh Yes, I can do that Next week works. Okay. I'm gonna assume it's yes. Clemens. You know, you don't choice. Yes And then just put an action item to bring dug a sandwich Yeah What's funny is usually during the main call if there's a Top it's I know it's gonna take a while. I will just eat during the previous call. I just didn't get a chance to today I'll message you at 10 to grab a granola bar All right, anything on this you guys want to talk about? Uh Okay, I guess we we need the answer to your action item before we understand who Is officially on the roster because I need to start doing travel plans That is true. So let me okay. Well, since I since you've nagged me enough about this topic Scott Which one of these would you like to run if any? Uh, I would love either the intro or the deep dive If I don't know no no within the you know, hey, you can't be that broad Um, I'm assuming each these has at least two two presenters Yeah, right, right, right So which of these which are the topics between the whole long list do you want to sort of own? I think it'd be kind of cool to do the uh the live demo Um, you talk about this one or up here Well, you whichever Okay, you know, I'm happy to do whatever. I just wanted to know if I'm on the team You're gonna get kicked off the island Scott. Um Well, I because I know you you you you seem like you have a lot of constraints relative to Uh getting child approval in the sense that you need to get done sooner rather than later Because you keep poking me on that. So what I'd like to do is See if I can get agreement at least put your name on one thing now So at least you can not lie to your management team and say yes, you are you will be talking Yeah, right. Um And glad you sound like you were gonna do something here or you think you're gonna really really try What if we tentatively scott put you on the hook for in essence part two of the intro to cover these things Okay, what did people think about that? Is there anybody on the call who says no, no, no, you really wanted to do that Okay, and then we could figure out the rest later. I mean, obviously if you guys really um Want one of the particular topics? Um You know speak up. Otherwise, we'll figure it out later Okay, yeah anything else All right Cool. Thank you guys very much We'll talk again next week. Okay Have a nice lunch. Okay. Bye guys. Thank you