 Hello, everybody. Is that John on there? Indeed. Good morning. Good morning. Hey, Tommy. Yeah Daniel Hello. Oh, is this your first time on the call? I apologize if it's not. I was here last week Okay, did I get your company affiliation? I thought there was somebody I missed last week Oh, you're Google never mind. I got that. Okay Slinky, how's it going? I missed last week. There's somebody new Hey, class Hey, Kristoff. Hi. And well, you there? Hi there. Yeah. Hello. Hey, Tamar Hey, hey, Doug. How are you? Did I spell that right? I can never remember how to spell your name There's just some names I can never spell right and Hey, Brian Happy Thursday. Happy Thursday. So you decided to join us instead of the other community call, huh? I did actually We got a pressure on that Say it again Don't maybe get regret my choice, Doug Now we kind of a pressure on them to get them to move that meeting because I really want to attend that one, but Okay. Yeah, if if you're also having that thought I almost emailed About the meeting this time around so I'll go ahead and send an email about trying to get it to not overlap with this Yeah, that'd be great because I mean if it was just me or you then that'd be okay But there's quite a few people who I think want to attend that meeting to who are on this call. So Yeah, I think I think it makes sense for people to be able to be in both. So Excellent, thank you. All right back to the fun Eric Good morning. Good morning. I'm ginger Howdy, howdy Lance Christian, I know Clemens is back from vacation. I wonder if you forgot. All right one more minute. I think it started Let me ping Clemens All right three after it's if I got everybody I think so small group today. Okay, let's go ahead and get started Let's see. Okay. Anything from the community that people like to bring up. That's not on the agenda All right, move forward So we talked in the last week's stk call about switching back to having a call every other week since we seem to be running out of agenda items And I posted a message in the slack channel like I said, I would and there was no objection So unless someone raises objection now, what we're going to do is switch to To go back to every other week starting next week. Any objection to that? All right, moving forward. All right workflow got some exciting news here. You're up teamer Hey, thanks Doug. Yeah, the exciting news is we got actually accepted. There's a sandbox project by the toc Yesterday, right two days ago. So we've been busy. We got our github organization and I'll pay paste the link I mean in the chat And other news are we have a java SDK. They have their own repos now we kind of copied what you guys do with cloud events, of course and We're working on again moving our repo structure over as as it has changed You know two times in the last couple months Um, other than that we're going on through an onboarding process right now, which I've never been through So there's a lot of little things that Toc is looking at making sure that we have um And yeah, that that's it um Yeah, and also one more thing we changed their meetings for months a month to twice a month. So our next meeting will be um next Monday the 20th and I need to update The the pages to reflect that so yeah, so for monthly meetings, we just changed to two times a month Every other week. So that's it. Thanks Cool and congratulations. I know you put a lot of effort in there I know there's a painful process, but it's it's exciting that finally went through Yeah, that was interesting to say the least Yeah Oh and one more question Doug if if can I ask real quick? I'm sorry. Do you guys know a guy called josh berkus from redhead? I know of him. Yes. Yeah. Well, he asked me um in contact with him and he actually asked me They apparently have some sort of booth demo videos for cube con in august And I don't really know what that means to be honest, but they're looking for like 10 to 15 minute videos They can just play um on some sort of booth type of setting And I was wondering if we do that for serverless workflow We could also add the cloud events in there as well And I'm sure that would be fine with it Maybe we can do something together as teams to create some sort of demo videos of something or other Um and and send it to him, but but I'll send you his email and then we can figure out exactly what what to do Yeah, actually that the that's a great topic because that is actually the very next topic No, it's good. Um, but before we did Excuse me before we jump to that Do we have any questions or comments about the rest of the workflow stuff before we jump into that? Okay, now hearing any so let's go ahead and jump into that because I got a similar email like you got about this And I wasn't quite sure what they meant by having a booth because I thought everything was virtual Well, apparently they're going to have virtual booths as well um And no, glad you joined clements because I wanted to ping you on this too since you and I are both presenting there um So basically there are three different options. Well, I guess four options But fourth being not going to do anything at all, but there are three options are We you know, do we want to actually have a booth? Um, which is Basically it's a virtual booth like you see here on the screen and you can have Slides you can do videos you can have downloadable material and basically I think the the point here is that people can just virtually walk up See a video that's playing constantly or download material, right? So it's not nearly as as interactive I don't think um, I think you can chat with someone If you want to do a chat they have chat they have chat and stuff like that Yeah, okay, right, but I think in creeping around here ginger that the other option is more Like face-to-face virtually interact it right rather than a chat. It's a zoom call. Is that right? Right. So the the second option I think gnats will probably do the second option just because you have more control Over it and it's a little bit more focused. I think um I'm not this is all new for us as well because this is the first time we've done anything like this Or also concerned if we did a booth about how much content we would actually have to put up there And and I don't know how much Feedback we could get from it. So we don't know if people like it don't like it other than that So I think we're going to go with the the zoom as well right Okay, and then obviously the third option is to do a combination of both And so my question for the group here was Is there any interest in doing either of these two options or three options? I guess Because it is if you look down here, I know it's a little small print But I wanted each one to fit on a line There is a fair amount of time commitment And I don't know if you have to necessarily do the entire All the hours listed for for all the days or just a subset But it is a commitment from folks and I know that Not being there physically makes it harder to make a commitment because you get pulled off on emails and other phone calls and stuff So if if people do want to do this, then I think they have to be prepared to To make it a real live commitment and not just say, yeah, I'll do it and then not show up God rather say no than have people be disappointed in us and not meeting our objectives Yeah, and the time zones for the us Especially pacific time are very very very early. Oh, yeah Good point. Yes Okay, so any questions about what's going on here before I ask the question of did people want to do it or not People understand what we're sort of talking about here And here's the list of materials and stuff At least for the booth Okay, so let me ask do we have anybody who wants to Who thinks it's a good idea and is going to volunteer to to sign up for either of these two options? And I believe I have to let them know by the end of today or tomorrow. It's it's a fairly quick decision Should I interpret silence as no one has any interest in doing anything? Okay, I'm gonna assume that So the decision by the group correct me wrong is we will not do anything True Well, do you want to do anything? I'm torn. I gotta be honest with you I I kind of like the idea of having something just to keep our name out there But I honestly gotta say I don't know if I have the time to put into it to make it worthwhile I mean I might I might be able to do an hour here or there, but If it's that random, I'm not sure how we're going to get You know the impact we want to make it worthwhile I I think of option one as an interesting marketing idea Um But I'm not useful. I'm not sure how useful that is I mean, it's a great what I mean is marketing experiments. Yeah Well, meet what we should do Is have ginger beer guinea pig and see how it goes for nats and then and then look at the next time we're out I feel like we're a guinea pig for the mcf for a lot right now. So, um I think and I have not gotten confirmation from katie yet. I think we have to Tell her today if we're going to do anything um my assumption for the zoom so option two Would be that we would be able to And this again the assumption we would be able to pick times and then they would be on The um schedule like so for the physical one when we had a maintainer booth Um, we could tell them when we were going to staff it and it was on the schedule So my assumption is it will be the same type of thing So you can say we're going to have this zoom call or whatever From this time to this time and they would be on the schedule I don't think we have to have an open zoom call for that whole entire extended time I don't think but again, we'll find out I can respond and let you know what katie comes back with Okay, she said she said she'll Come back tomorrow. So if I let her know today, then they would contact us tomorrow. So Okay, well, let's ask that question then so if it is a matter of picking a certain number of hours um across any of the four days Um, even if it's just you know one hour a day kind of a thing Would people be interested and be willing to sign up to host or to be part of a zoom call You came off me because I'm gonna pick on you. Yeah I could have out with something. I mean, it's my time zone. So That is true. I could put more pressure on the european folks Um But I don't know. I mean it's thank you claus for it for speaking up, but I don't want claus to be the only one Is there anybody else willing to volunteer? Okay, tell you what I don't mind volunteering. I'll raise my hand to do an hour. Um Maybe I can probably look at maybe doing an hour a day Especially since it means pretty early in the morning here, which means it won't overlap with another call I don't mind waking up early And so tell you what so ginger, we'll pick it back on your idea I'll send them a note saying if possible. We'd like to do option two We just don't know the exact hours yet, but chances are it may only be an hour a day and make sure they're okay with that Yeah, I think that's probably what we'll say as well. So and we're kind of taking this as a prelude and practice to Boston as well because boston's going to be virtual as well. So Okay, and you have any objection or comments about that in terms of in terms of a direction Okay, now going back to Tim or your question What what's your thoughts on this? Did you want to do something? I was now that you're a full-fledged project um Actually, let me back up. Um I was kind of assuming that we would do this I could say ginger, do you know is this for This is this for projects or working groups? I'm guessing it might be just for projects As far as I'm aware, it's just projects. Let me look at her email again Graduated incubating and sandbox projects. Okay, so it's just projects. So this would be a c e thing then Okay, so that means Tim or you guys from the workflow side now that you're real you get the option of doing it as well Um, I guess it's up to you guys to decide whether you want to You know do option one two three or or nothing Right. Yeah, I mean you're just gonna you you guys just gave me a lot more information than I have previously No, I just got an email saying we're looking for booth demo videos for cube con. Do you have anything? It's all I've known so far. So this thank you for sharing all this. I'm happy but yeah, I mean, um I my initial thought maybe we can join forces together to kind of create something together If if not, then that's fine as well. Whatever you guys decide um, but yeah, if if if You guys want to put together like a couple two videos to make him have something longer or whatever That's fine with me. I'm open. I'm sure we are open for everything Yeah, so so I think our current thing is not necessarily to put together a video as much as have A zoom call now we could combine if you wanted to right we could make it a zoom call assuming that the The organizers are okay with this we could say You know, we could do a single zoom call where it covers all serverless related things, right? cloud events the other spectrum working on in cloud events as well as The workflow stuff in and we can call it a serverless thing Even though it's supposed to be a project oriented thing and see if they're okay with that So it's a little bit more of a work group thing. Um, but if they really really want to keep it focused just on a project perspective then I think um Then I think merge the two might be a little bit awkward because I don't think I don't think the two projects go Close enough from an outsider's perspective to to make sense. So you may want to look at doing your own zoom call or thing Or I'll ask Yeah, I'll ask too because Because I think if we can merge the two it may be easier for us to man the zoom call Right, because I think we could probably get people on our side to at least answer some very high level questions about the workflow spec and likewise The workflow folks could probably answer some cloud events question if they really had to because I know you guys are Chinese cloud events with the covers as well so in terms of Getting coverage for more hours. I think combining forces might be better But only if they're okay with that Okay, so I'll reach out to them and we can talk offline, but I think we have to get an answer back Today or tomorrow with the latest kind of a thing Okay, okay, so Okay, any other questions or comments on that topic All right before I jump into prs and stuff Are there any other topics people wanted to bring up that I forgot that the agenda I'm sorry that me again. I thought so much in this meeting. I just wanted to kind of tell everybody And again, it's this redhead thing. We have these things called tech Tuesdays it's some sort of video that can be from 30 to one hour long and it's an interview style thing where people just Go on there and and learn about some different technologies And there is opportunities in august if anybody here is interested to kind of promote cloud events And let me know just send me like a note Or an email or whatever and I'll try to find some some some schedule for it If you guys would like to take that opportunity That's all Okay. All right. Thank you All right anything else All right in that case slinky. I believe this one is yours. So you got to go first I did mention this on last week's call. So people hopefully took some time to review it But you want to just refresh people's memory and what this one's about? Uh, so this is a follow-up of the The pr we uh I did about uh adding some rules About sdk governance And this one had some Criteria's to to add new maintainers to the sdk projects. So I'm waiting for feedback basically Okay So let me ask some of the sdk folks on the call and I see lance and clements and I don't know who else is there Anybody have any comments on this? Did you folks get a chance to review it? I added some comments. I think it was last week when When it was first First submitted and you know, I'm generally okay with it. I have a few comments there Okay, but those were addressed since I don't see them anymore, right? Huh? Yeah, I think I just sold your comments lance Oh Yeah, there is a Let me just see if there's anything else. So do you guys need to review um To go back and forth on these offline Yeah I didn't see that you had responded So, yeah, I'll I'll follow up on that. I'm okay Yeah, we'll have a full solder of people jump into this question too. Yeah, okay. Okay. Don't need to rush it then Of flying of course. Yep. Okay. Sounds good Perfect Any any I guess I should ask any questions at this point in time for francesco. Just Maybe I want to bring anything up or do I just take it offline? Okay, I'm gonna hear any questions. So we'll do it offline Okay, this one very easy. Just didn't merge it because no one bothered to add an lgtm I just noticed we missed we're missing the php and rust Uh, stks to the readme any objection to adding those All right, I didn't think so Obviously feel free to lgtm easy stuff like this if you guys want or if you notice All right, this one Okay, so on last week's call I introduced the idea of adding a unique identifier per service Um, that is immutable so that on a subsequent query you can know whether This is the exact same service or not because maybe every bit of metadata has changed But obviously if this one field can't change and you'll know it is the exact same thing just with different metadata um Now claus you asked a question about Down here, this is this is the interesting one. I didn't quite understand You're wondering whether this belongs on the service or the service. I'm sorry on the endpoint or on the service And I didn't quite understand what you meant by discovery endpoint Well, um in a scenario where um, you have different Discovery endpoints Assume you you have something like an intermediary or multiple intermediaries that um provide this um Discovery to this event or the service um Does it have to be the same uid? for the service on all of those discovery endpoints or So is it identifying the service? Or is it identifying the service entry on a specific? discovery endpoint Okay, I want to make sure I understand the scenario. So I think what you're saying is let's say you have a Discovery endpoint that people can hit directly But then that same discovery endpoint is available through something like an aggregator or something like that. Yes Would the same service uuid appear through both portals basically or through both endpoints? Yes. Yeah Anybody have an opinion on that? I I was in my comment. I was I was willing to sort of leave that up to an implementation choice But I don't know whether that's too loosey-goosey What other people think about claus's scenario? Oh come on. You guys can't be that quiet So okay claus So I I said I didn't I don't have a clear opinion on this Yes, because I think we we just don't have those scenarios yet. Um So let me ask you this since you seem to be the only one speaking up on this one. Um Do you think we need the id at all? Do you agree that I that with my base scenario? It's a Good question I mean because it is possible that I'm I'm way off the deep end and this isn't needed at all I just I just don't understand how to I remember that we we had that discussion where I was asking how a Discovery endpoint can assure that Those names are always unique if it's aggregating names from different sources services and So I'm not sure if that was the motivation to to add this id here Yeah, it wasn't so much because of the name thing in terms of an aggregation It was more a realization that Anybody may have made a typo when they added this service entry And I as I was looking through all the various attributes I didn't see one that jumped out at me that said It doesn't matter if you made a typo. You cannot change this because it's gonna it's gonna mess with people Everything seemed like it was it ran the risk of it may change over time, right? You may add or remove types You may have done a typo in the name. You may have done a typo in the description I couldn't find anything that didn't fall in the category of someone may have goofed, right? And they don't want to They don't want their users to view this as a brand new service, right? They just want to update the metadata about an existing one And that's and that's why I came up with a need for something. It's immutable like an id Not something that something that's something that people would typically expose to their users It's more of an internal usage kind of a thing Okay So I don't know it's it's just um UIDs can can be quite useful in some cases, but I always have also mixed feelings about them um I did some Research on I mean for example in kubernetes. You have both Also, you have names and your IDs and used study in a different way mm-hmm So names are kind of providing a stable link and and while When you access something over the uid you are sure that you're accessing the very same instance again um So I was wondering if that translates somehow to to our situation and that's how I came up with this question about Is it identifying that entry or is it identifying the service? and As I said, I don't really I mean what I Proposed here is also to to just Accept the pr but maybe create an issue to remind us to think about this later on once we have more Scenarios we are looking at or we started implementing it mm-hmm. Okay So madius you're you're you're uh off mute. Did you want to say something? Um, basically, I'm agreeing to it that would close that it was just I think about to add something would close already. So, um We uh, I agree that we need probably more scenarios to decide this but Would be very helpful especially as I explained That we don't want to specify something that can't be changed Okay Sounds like some kids are having some fun in the background um Okay, so so claus you you you said something in there about you know Maybe accept the pr and open an issue to remind us to go back and revisit this What do people think about that? I'm I'm torn here because I do think this is needed. So I obviously that's why I open the pr But the fact that I'm not here Speak up makes me a little bit nervous About whether I'm the only one and I don't want to add something if I'm the only one that thinks it's needed All right, are people being silent because they think yeah, it's needed and you're okay with it or you're not people just aren't sure I will start picking on people if I have to get some opinions on this Okay, you're gonna make me do it clements. I'm gonna pick on you since you were on vacation for two weeks Yes, what's your what's your take on this one? I don't have I've not formed an opinion yet because I was on vacation for two weeks That's a nice out. Okay Sorry Yeah Oh, okay, let me pick on somebody else. How about mr. Mitchell john Can you hear me now? Yes, I can I I I haven't uh, I have not thought about it um, I think uh, I think given where we are today my bias is sort of with claus that uh I mean I agree with your initial impetus that I think we need something to deal with those Whatever you want to call it sort of life cycle conflicts Right, whether it's a typo or other thing. I just haven't thought through the implications of the You know, how is this actually going to play through? So I guess my top out is uh, I would rather have more time Okay Okay Fair enough. So we had at least one request for more time So why don't we go ahead and and uh and do that? I would like to see if we can come up with some kind of decision By next week's cogs. I think this one has been out there for two or three weeks now um And I don't think it's a huge controversial thing But I think it's more a question of people needing to take the time to look it over and think about it some In the meantime Maybe claus I'll reach out to you offline to see if we can try to address your concern here If not, we do like the journal direction then we'll open an issue to remind ourselves But I'd like to see if I can address your concern in this pr if I can Anyway, brian your hands up Yeah, I was going to put myself out there with maybe a really naive question. Um, but uh, if a client has received one of these IDs How long do we expect it to be valid for are they allowed to stash it away and come back a month later and expect it to still be valid So so mine to that would be It's not a question of how long are they valid for because I think I think it's it's valid as long as the service is alive within The scope of this discovery endpoint right So it's not like this is a temporary idea in any sense right as long as this service Exists in the discovery endpoint. This is the unique idea for it And so that remain is intended to remain true across Discovery endpoint restarts and across service restarts and across all time As long as that service Exists and you want it to be known as the same service that it was x number of days ago. Yes Okay, because the minute the minute the value changes then anybody who received it is going to think oh, this is a brand new one Does that answer your question? Uh, yes, uh, it does. Okay. Thank you. And actually that that is a good point I'm not sure the text in there is as clear as that and I'll try to beef up the text a little to make that perfectly clear So it is a good question Okay, so I'm hearing people want more time to think it over. It's fine Any last questions or comments on this before we move on to the next one? Yeah one, um, so what is the url for it? It specifies how to access this Service to subscribe that's in the description So why is this not being unique? Why is this not the ultimate identifier? Um, or if if another identifier is needed, could there be more than one url to access the service? Okay, so you switched over to url. Okay, so to me the url wasn't able to be used as a unique identifier because People could move where their hosting service is hosted, right? So for example, maybe Instead of today it being a url of ibm.com in it. Maybe it's discovery endpoint dot ibm.com, right? But it is still the same Uh service that's being deployed. It's just we're just hosting it at a different endpoint Right, so that's why to me that that the url field might actually change over time But it still could be the exact same service under the covers Does that answer your question? Yeah, thanks. Okay Okay, unless there are other questions like we can move on we'll defer this one for next week I mean it I will just say that it sounds like you're driving towards the id really being tied to The service and in no way related to the discovery endpoint um Which is in a sense a resolution to that to that question on the pr. I think Yes, I I think you're right. I think that has direction. My mind is going. Yes And so the discovery endpoint is more just, you know, your htp server that's Communicating some back end information. Yes And I and I could try to work some text around that and you're right I think that might help answer class's question to some degree Okay Cool. Next one. I took an action to write up a draft of how we would do pagination For at least a discovery spec, but as I started writing this up I realized that we actually might need this For the schema spec as well or at least some other specification out there anything that basically does a query over records to be to use generic terms and so Um, what I decided to do was to rather than embed this inside the discovery spec was to actually create a separate document itself that talked about how to do pagination just in general and then we could say Or our pointers to it from the discovery spec or any other spec that might need it And the basic approach I took here was to steal what I saw from A github and referencing the actual rfc number, but basically When you do a query you can specify An initial query of something like this Right where you specify the number of records you want to get per chunk size equals 100 And then the response can include some hb headers with links that tells you for example how to get the next set Or the previous one if you wanted now The one thing I did do was out of the option for the server to return and it expires um And the reason I did this was because I didn't want to assume that at this spec level I would say this so at the spec level I didn't want to mandate whether the That whether the data that could change on the server could change Or not, right? I wanted you be I wanted the server to be able to in essence support both meaning When they get the initial query up here Do they create in essence a result set for that particular query that gets persisted off to the side that way if the um If the result if the data in the back end server changes the results that become static, right In order to do that. I wanted the server to be able to return Um some information that says how long is this data good for that way the client knows They better retrieve all the data before that expires time otherwise it may go away Without that Then you're back to the case where the data on server doesn't change very often So you don't need to worry about this situation and everything could be kind of stateless Right It's a little bit funky to think about but I wanted to make the spec generic enough to try to support Both use cases and the way the way I wanted to make it or the way I wanted this client to know Which case he was in was whether the expires time popped up there Now that's not to say that there couldn't be other information included in here that That's opaque to the client meaning let's say for example The server is in this scenario where it's a static. I'm sorry not a static a a temporary data set that gets generated But he needs some sort of unique identifier on each subsequent request to identify which results set to that is That's being queried over right so they may include not just a size query parameter But maybe some sort of identifier in there and that's okay The client doesn't need to know about it. Doesn't need to care about it. This link is completely opaque to them They don't know anything about it whatsoever The only thing they need to know is to use it and if the expires time is here They need to finish their results that retrieval before the expires time happens Okay, so really the all they need to care about is just whether exists or not and not really understand much more about it So anyways, so is that the is that the uri you're getting back? Is that the idea? So this is the uri you get back in terms of where you're supposed to do your next query or i'm sorry This is the next one because the the rally goes next right So here's the uri you send your next one too and you just treat it as a opaque blob or opaque uri Just do a guess if we get to it And if you're quick you don't ever need to even think about the expires right But if if for some reason you let you know that you're very very slow in doing the retrieval The expires time here tells you well, you better not be too slow because that results that may go away at that expires time There's a whole negotiation mechanism in in hdp for this Is there a point me to this back and I'll I'll leverage that yeah So there is a if you take a look at That Effectively for interacting with caches if you if you page forward you might be might want to go and page back And so your hdp browser knows about this and the servers about this so if you are if you have a Pages and you page forward and then you page back Then the server may go and give you a well I don't have anything that's modified modified and gives you a status of I haven't looked at this in a long time, but 400 something And then then you get the answer from your local cache So that is all of course in rc 30 72 32 72 32, okay, and then you can look at 3.3 Okay, because I did find rfc 59 88 which is where I got this linking stuff from But I did not look at yeah 72 72 32 has all the preconditions and Last modified and e tags, etc. All that all those things So I think what you want to model here is already In that spec it doesn't end up in the in the uri Um, but it ends up in headers, but I think that's mostly um, what the What what you're looking for Okay, cool. I will take a look at that. Yeah, because if we can just Point to that rc then we could kill my entire idea. I just think I'm just I think we need to have paging as well But there's a I'm sure There is this, um Um top and skip Mechanism that is probably similar to what you have here. Yeah, because I think There's a there's yeah, because I think that's how we do paging in our services Um, and but I'm sure there's some rfc out out there which already defines that Also just an old data. I think yeah, yeah, yeah, exactly Old data. Yes, and and as things go I just look at a at an sap block block block entry That talks about top skip and count Okay, well, yeah, so you take a look at old old data is Is probably not bad for that and I'm guessing that if old data does this then stuff like What's that thing called? Graphql Might have something something similar Cool. Okay. I will definitely take a look at that. Cool. Thank you And guess there's nothing more to discuss on this one then let me go off take a look at that rfc and see if we can just leverage that puppy Fabulous Yep. All right Any other hello questions comments? All right, cool. Thank you Clemens for the pointer Um, all right. Now this one was just open. I think yesterday. So it's probably too soon I was definitely too soon to to um To accept and thomas is even here um Cool. Thank you. Thank you class. Um, okay. So obviously he has a I guess an open api for the discovery spec I suspect no one's had a chance to take a look at it So please do so seems fairly short Okay Any little comments questions? I assume this is something we we probably do want assuming it's technically correct Okay, in that case um This one christoph. I know you just opened this today, but would you like to Explain how you tried to address this problem Yes, I can we talked about it. I think two or three weeks before. Um, so the main One issue is that in the hp protocol binding We talk about content modes and we have two modes called binary and structure And they have exactly the same name as the two message modes we define in the spec and that is very confusing because One assumes they are the same thing, but they're actually not But it's obviously very confusing because they have the same name. So I try to be Um And they obviously relate to each other. Um, so the the real difference pops out once the batch mode comes in which Happens to be a structured message mode at least in my opinion Because it fulfills the definition of the structure of a structured mode message Because it contains both the Attributes and the data inside the message So I try to clarify it here by being more explicit in the protocol binding And if you scroll down to the spec Um, I basically already, um Both the bottom half in the uh, pr by uh, What's his name, Tim? No, sorry. It was Grant Yeah, Grant. Yeah, sorry. Um, yeah Yeah So in the below the message modes the upper part I said That for the binary mode message usually they're just used as they are and uh transport protocol doesn't do much But for the structured mode message they're often embedded And then I added some more details below what that embedding can mean. So sometimes there is more Uh things added as a wrapper around the message. So we see this especially with jason Um, so you may add other things or you may batch several messages together Okay Any questions for christoph always on the line. Yeah, what is so I don't understand what what 139 to 141 ads Yeah Well, I try to clarify it for For I think a lot of people are confused I agree that technically all of this Is already there, but it's just a lot of people stumble over it So I'm trying to add more text to make it easier to get So you're introducing the the notion of an envelope And I'm not sure there's an envelope in htp So But I don't think the text carries that well Because I mean there's no htp is not a good example. So htp does not have an envelope. That's correct But if you look at I don't know Kafka if you look at Uh, for example the the pubs are binding that I looked at over the last few weeks They all have an envelope around it. So Kafka calls us a record Yeah, yeah, actually it's it's not even true for Kafka. It is the value Of a key value pair which makes up a record And then for aim to pee it's the it's the body of of the aim to pee message But there's no envelope there if I if I say envelope I think of of soap for instance as a abstraction that sits between the transport container or transport body and the And the payload And that we have in no case Yeah, fair enough. I used I think a different term first but Doc used and both I think I mean I'm happy to to Choose a different name or even drop the whole sentence And then and then I find I find sentence 153 Is actually could is is conflating is that is really conflating two things so for instance So you never use it once you use binary Then you never you you don't use an event format ever Because you're taking the payload of the event and you map that straight to whatever the payload Uh section is in your transport message, but the event format doesn't play a role here So clements. I'm wondering whether it'd be useful Um for you to take a look at the original issue Yeah, um just because I will out while grant open the issue at least I think grant opened it I think it was on behalf of somebody else at google and they were confused by some of the terminology we're using Um, so maybe any help if you get that background first then to better understand Oh, okay. What we're what what what what the what the desired goal is put it that way Okay, yeah, I'll look Yes, because the the um, I think the envelope. So the envelope term trips me up and that might be my age But uh Yeah, so I I think I I I think I know what sort of clarification chris. That was after Yeah, let me look at that and we'll we'll talk about that again chris. So I'll probably um, Reach out to you directly on this Okay, okay. Yeah. Yeah, thanks. Yeah, I mean it obviously it was just open today. So it's too new to prove anyway. Um, yeah Yeah Okay, any other questions on this one or points of discussion people want to bring up Okay, in that case moving forward Um, but um, I don't think there's anything on these. I know jem is in here Francesco, I assume these are still on hold, right? Mm-hmm. Okay. All right. So interrupt. So, um, I know remy was working on implementation I have been as well and remy said he couldn't make the call today and from my side to be honest I haven't had a chance to do anything for two weeks to work on this. So there's no changes Um, does anybody have any Comments feedback on any implementation they may be working on at this point in time Or even just want to mention that they're working on one Okay, not hearing any Okay, so obviously, you know, we'll try to keep going in the background. Um And when people do have something that's uh runnable will look to do some sort of interrupt testing or something on those lines We'll see how it goes But at least from my point of view it is helping to flesh out some issues like that id thing that I brought up earlier Okay, um, technically that's the end of the agenda. Are there other topics people would like to bring up All right, not hearing any Uh, I think I got everybody on the agenda except for grants because I think grant you just joined You there grant Yeah, yeah, I just joined. Okay, cool. Yep. Um, and just let you know, I suspect you may have joined because the sdk call um However, we agreed to meet every other week and we're going to start doing that next week. Just let you know Okay, uh So it's Okay Man, that's Yeah, every other week starting next week. Yeah Okay, right. Did I miss anybody else for the attendee list? All right. I think that's it done. Cool. Thank you everybody for joining We'll talk again next week and please review the new prs when you get a chance I'm billus Yep. Okay. Bye everybody Bye. Bye