 Thank you, just wanted to get your attendance in there. All right, excuse me. All right, so let's jump right into it. I don't think there's anything necessary to talk about the AIs, Austin's not on the car call. I'm gonna ping Austin offline to see what he wants to do with the next SDK call because I think it's been a while since we had one. I think we need another one. All right, community time. So this is an opportunity for people who may not be normal people on the call or normal visitors to the call to bring up any topics for discussion. Is there anybody on the call who would like to bring up a topic for discussion? Who isn't normal here? All right, cool, moving forward then. Okay, Austin's not here, but we haven't had any SDK work group meetings, so there's nothing there to talk about. Kathy, is there anything from the workflow subgroup that you'd like to mention? I don't know, thank you. Okay, Ku Kahn-Shanghai. Clemens, Kathy and I are still working on the charts. There have been some updates since last week, I know based upon what I saw about an hour ago, there's still more work that needs to be done, but obviously anybody's free to take a look at the current version of the slides if you'd like. The link is right here on the agenda. Any suggestions or feedback is welcome. We also have a phone call immediately after this one to discuss it. If anybody wants to join, you're welcome to join that as well. Just let you guys know. Interop demo. Okay, first, I need to seriously apologize here. I actually did create an invite, but like a dope. I forgot to include the working group or the mailing list for the group on it. I actually included just myself. It was a very exciting conversation though, but just let you know. But so I'm gonna probably set up another phone call to discuss by interop at some point, but in the meantime, if you're interested in the interop demo, please go look at the cloud events demo Slack channel that we have at the private channel. So if you're not on that, just ping me and I'll invite you. But I would like to try to get some offline discussions going there about the interop demo, in particular about two hours ago, I think. I pasted a rough outline for the flow that I was thinking we may wanna do. It came after a discussion that Klaus and I had earlier today. So if you like it, credit Klaus. If you hate it, that's for the parts that I added, but please review it. If you have any feedback, let us know. I do wanna get that going relatively soon. The scenario that we're kind of looking at is not terribly hard. So it should be easy for anybody who wants to participate to join in. But I'm not 100% sure it highlights all the right points of the specs themselves. So we're looking for some feedback there or ideas for how to beef it up from that perspective. Any questions on any of these four topics before we jump into PR discussions? All right, moving forward then, PRs. All right, let me just do a quick double check and see if there are any new votes since the call started. I think Fujitsu has lost one to vote. Okay, so the vote's now closed. Last time I checked, I think it's about 10 to one in favor of 321 for the property casing vote that we shared last week. So 321 is the one we're gonna go with. What I will do then is I will close out 319. Clemens, I believe we can't accept 321 as it stands because there are some conflicts. Are you able to take care of those at some point? Sure, I will be. I've been occupied with other things and I've also been traveling to the US. Yes, I will go and fix all that. Okay, thank you. So let's see. Yeah, go ahead. But that's, did the vote close? Yes, the vote is not closed, yes. Okay, great. Let's see, update 321. So I'll fix that as soon as possible. Hopefully I'll find some time today even though it's busy. Okay, just that curiosity, I can't remember for sure, did you update all of the specs or documents that you have relative to that or was there more that needed to be updated if you did? No, I did and that's probably what the conflict comes from that there was a PR that we merged later in some other way and that might have, yeah, so I'll do the rebase. But I'm not gonna, I don't expect that I'm gonna do any text changes. Yeah, okay, yep. Okay, cool. So once the rebase is done, I'll then merge that one in. So thank you very much for everybody for voting. Let's see, move forward. The protobuf format PR hasn't been updated since last week and I don't think there have been too many new comments since last week either. So two questions here or two things. One, please everybody when you get a chance, look at that PR. I know it means it's an important PR to a lot of people out there especially obviously the protobuf people. So please look at that when you get a chance, the more eyes the better. It's actually relatively small PR. But also, I'm trying to see who's on the call here. So Scott, you might be the only Googler on the call. Could you poke Spencer for me? There are a couple of comments in there that I'd like to get his feedback on either to say I don't like your suggestion or to update based upon the suggestion. He hasn't had a chance to, or he hasn't commented on the comments in the PR. So maybe you could just poke him a little. Okay, we'll do. Cool, thank you very much. All right, any questions or comments on the protobuf PR before we move on? All right, keep them going then. The versioning scheme, we briefly talked about this last week. I was wondering if anybody had any new, I think it didn't change this here. Any new comments? I know, Eric, you had some comments in there and you were suggesting possibly looking at, what was it? Schema VR, that's an optional alternative. Anybody have any comments, questions on this one? I enjoyed your comments last night quite thoroughly. Okay. It seems sensible. If the notion is that if any breakage could occur, if there's any possibility that you're always gonna go with the effectively major, I don't know that there's a lot of importance in bringing that in. Okay, cool. Okay, well, has anybody else had a chance to actually look this one over? Okay, I'm gonna assume silence is no, which is not a good sign. And I definitely don't wanna push for a vote because I want people to review it. I think while it's a small amount of text there we're adding to the race process, I think it is kind of an important decision. What I would like to do is put a time box on this though. So what I'd like to do is push for either a decision or at least a discussion on next week's call. No discussion implies I'm gonna ask if there's any objection to approving it, but I do wanna give you guys at least one more week to review it. Does that sound fair? Yeah, that sounds good. Okay, cool. Thank you guys, I don't, I don't. Because you're wanting people to make a decision on this, can you send something to the mailing list? Ooh, good idea. I don't know if people that aren't here. Yes, that is an excellent idea, thank you. Thank you. Yep. Does this word remind you to send it just to yourself? Thank you, Mark. That hurts, that really really hurts. Sorry. Thank you. All right, final item on the agenda is gonna be a really short call I think. I think it was Klaus, I apologize if I gave you the name wrong, but somebody asked me earlier about when we're gonna cut of zero to point two. And I started looking at our mouse, our roadmap document, looking at the zero point two items we had here. And I actually think we're pretty much set for actually most of these things. We did the learning, we have some draft documentation out there, user's guide, I'm assuming that's sort of the equivalent of a primer. You guys can obviously think about that one. These two are interesting. So I don't know if, I don't know about any large design decisions that are looming, at least not once the people have actively brought up or any required attributes. However, what I was gonna do was I was gonna look through the list of open issues to see if any of those fit the categories of those two and then bring those up for discussion. I would appreciate another set of eyes looking over the open issues to see if there's some out there that I missed during that review. But if I'm correct and we don't have any really big outstanding ones, then we may be able to assume those two points are behind us. And then really, we have the interrupt demo which we're working on right now. It may be just a matter of saying, do we think we have the initial set of protocol and serialization mappings that we want? But anyway, the main purpose here bringing this up is to ask you guys to please look open, I'm sorry, look over the open issues. Or if you can think of things that fit in those three categories, bring them up as new issues. But I'd like to see if we can sort of have a discussion on next week's phone call about whether we think we're either at 0.2 or close to 0.2. And if we're not there yet, what are the outstanding items that we want to tackle? And then start, make sure those are on the agendas for upcoming calls and discuss those. Persistence, Eric. Yeah, you're right. I think there is actually an issue out there. I don't have the issue number off hand, but please take a look at that one. That might, from my personal point of view, that gets into a little bit of implementation detail, but I think we should have that discussion in the issue. So please, people take a look at that persistence issue since Eric's specifically mentioning that one. But I'm pretty sure there is an issue out there for it. All right, does that sound fair, everybody? We'll try to have a discussion next week on where we think we are relative to 0.2. Not hearing any objection. Are there any other comments or questions relative to that discussion? You'll want to bring up now. Okay, this is going to be a really short call, guys. Are there, oh, thank you for the link, Eric. Are there any other topics or PRs people want to bring up? I think all the other PRs are blocked for some reason, in particular, Fabio's, even though it's a relatively easy PR, it came in, I think, just yesterday. So it's too new for us to review. Are there any other things relative to PRs people want to talk about? Okay, are there any other topics in general you want to talk about? Oh, I'm sorry, go ahead. So I have a question about the version 0.2 Milestone. Are we going to be able to time that with the very early data of the SDK work because a new version of Cloud Events and actual very early SDK Milestone would be a great thing. Like, people could actually start implementing this. Version 0.1 had actual industry interest and 0.2 would come with some, again, even very rough SDKs, it would be amazing. I think that is a wonderful idea. And that's a great reason to have a discussion or have an SDK work group call. If nothing else, that would also force people or have a good forcing function because I would love it if we could do 0.2 in time for KubeCon Seattle, which is not that far off. But it should be, I think there's enough time for people to at least get some beta level or alpha or beta level of their SDKs. I know, for example, Go is already out there. But I think that's a wonderful idea. What other people think? I think that we have to have some more pure reviews of the SDKs and understand how they align across languages. So I think it'd be good to, for Austin, be able to schedule up a call and have us discuss. Yep, okay, tell you what, I have a reminder to myself that I tend to be forgetful these days. Where is it? There it is. Okay, okay, I'll do that. Thank you guys. Anything else relative to the milestones or SDK work? Oops, okay, not hearing any. Any other topics people want to bring up at all today? I have one, Doug. Yes. So we have a situation in Knit of Eventing where an event source can potentially split an event into multiple events. But that concept is not really supported by cloud events directly. Does this group have an opinion on how we should handle that? If you split an event, you have multiple events. Like each of them needs to have a separate event ID because you're going to route them differently. And you might go and use, we have these tracing extensions where you might go and say there is a causality that's causing where that all comes from and you can go and follow through for tracing what that is based on. But if you modify, effectively once you create an event and you send it, it's immutable. And if you derive an event from it, that's a fresh event. Okay, that makes sense. So Scott, are you also kind of wondering about whether this gets into the whole correlation aspect? Like should there be a property that allows you to tie them back together? Is that kind of where you're headed as well? No, but I mean, it does raise questions about like the ordinal and the cardinal numbers. Okay. Okay. Any other comments or questions for Scott on that one? Well, I guess the question is what is the use case for splitting them? What are you achieving by splitting them and delivering them separately? It all depends on the, so we're building a framework. So we're not exactly sure what people will do downstream, but one of the things that's been requested is sometimes an event can come in to some sort of filter function and the result of that filter function is several related events and it consumes the original event. Okay. That sounds like the middle work case where you're accepting it in and then generating additional new events. Correct. Yeah, okay. Okay, sounds good. Thank you. All right. Thank you, Scott. Any other topics that you want to bring up? All right, in that case, just final agenda deal or process. Rohit, are you there? Hey, yes, I'm here. All right, Matt, are you still there? Matt Rakowski? What about Mike Place? Yep, I'm here. Okay, Luciano? Luciano, are you there? I'm here, I'm here. Tough one to keep. Okay, I got it. Yeah, I'm here. Okay, sorry. What about Nick, are you there? Yep, good morning, I'm here. Hello, and Matt Rakowski, one last time. All right, is there anybody I missed on the roll call? Okay, Clemens and Kathy, are you guys able to stay on the call here so we can do our next call right away or do you need to wait until the top of the hour? I would love to stay. Okay, that's what I thought, cool, me too. All right, in that case, everybody else is free to go. Thank you guys very much, and we'll talk again next week. Okay, see ya. Okay, bye, guys. Thanks all. Thanks, bye. Yeah, I haven't been able to write the slides as promised because travel was a little bit more involved than thought. And I'm busier here than thought, so as I said, all goes. And so I haven't done that homework yet. I apologize. Okay. But I will have it for next week. I'm gonna sit down in the weekend and go write it. Okay, Kathy, how's it going with you? Yeah, I think I'm done. So if you folks like take a look and then... Yes. Yeah, I went through with Doc last week, so Clement, if you'd like to take a look, especially the deep dive session, which you are involved. Yes. Where can I find it? Or are you gonna project? Yeah, here we go. You can talk about it now if you want, hold on a sec. Okay. I don't even know how to work that app. It's not bad. It's not bad. Let's see, agenda. Kathy, you wanted me to jump to the deep dive, right? Is that what you said? Yeah, I mean... There's Clement. Okay, there's your work flow stuff. Okay. So first I give a workflow overview. It's a use case example, just a use case. And then next slide. Yeah, this is just a use case. And then the next slide is, what are the key primitives of the workflow? I just take it from the spec and summarize it here. And then the next slide is shows how we use those key primitives to describe that use case, which is given in the previous slide. Mm-hmm. It's, of course, the easier to get across, use a diagram to show how to describe it. And then the next slide is, let me go, what's the next? Yeah, it's just in some information links. Yeah, I like, slide 22 is great. I like the visual tells a good story. Yeah, so that's, yeah, basically that's about it. Just first give a use case, describe the use case so I can summarize the primitives of the workflow spec. And then third is how we apply those primitives to be used to describe that use case. And then some important links, yeah. Now, since I haven't been part of the workflow workgroup, and that's basically just a function of time so far, but I will eventually, I will have to. What's interesting here in that slide is that you're effectively driving the state of the, the state machine kind of independent of the work that you're doing. Like you're, you're advancing the state machine and then you're reacting to the state changes by doing the work, which is a bit, that's a bit of the opposite direction of how things usually happen in workflows. But I think for illustration, that's good. Yeah, so. Like you go, effectively you go into the, you go into the by state, and then having gone into the by state, you then go and react to the by state by executing the by action. And that's usually it's the other, it's somewhat the other way around, but that's okay. Yeah, so it's like, you know, so for this one, right? When the user say, oh, I need event one is I need a stock trade, right? So that's an event state waiting for that event. So it starts as a, the starting state of the workflow is an event state. And that's, when that event happened, it goes through function one to execute, which is doing some authentication. And then it's going to transition to switch state and pass the function one's results over. In that switch state, it's going to see, check with the, check about the function one's result. If it's a by, it's going to change operation state, which is a bio operation state. If it's a cell, it's going to transition to the cell operation state. And then if it's in those two states, for example, in the bio operation state, it's going to execute on the function two, which is by operation. Yeah, I think my objection here is one that is a bit more fundamental, which is something that we shouldn't discuss. Like if this is the discussion of where we are in the workflow discussion group, then that's great. And I don't want to go and get in the way of this, but the observation that I have is that effectively the state change. So I'm just, what I'm looking at is this operation state by, and then when it hands off effectively control to FN two, right? That arrow, what that is, is really that's, that is not an event. That's a job message. That is a job message, not an event. Yeah. And that's the interesting things that were, oh, so you mean that to be in it. So that's not an event. That is a job message. Yeah, no, that's not the event is in the red. Oh, okay. So, ah, so effectively you are then wiring up the event path of, I just performed the transaction. You're wiring this back into the state machine. That's how you do this. Right, right. So when you go, yeah, no, that's not event. All right, good. So, okay, then I'm with you. All right. So I didn't, no, I misunderstood that from that picture. So maybe I should clarify that, you know, in case someone else could misunderstand that too. So event is only in the red. I think it's, so with the deep thought, I can actually set this up. So in my portion, where I'm defining, where I'm talking about the event spec, I can go in the intro and do kind of a compact, you know, one-slides definition of effectively, you know, a detailed definition of where an event really is and differentiate that from messages. And then basically forward reference your section and say, Kathy is gonna have an example. It shows that some things are jobs and there are messages and other things are events. And we're showing how both of those elements are useful within the scope of a single system. So the events versus messages discussion, is that something you think that should be discussed in the intro or the deep dive? I think we can also set that up in the intro. I have this, I have a presented that in the group. I think I might have, if not, yeah, I can send you, let me give you a link to a deck, hang on. That will take me one minute to find, because I have that in my public one drive repo of all the decks, one second. And it's actually one of my latest ones. So here Clement, when you say event versus messages, right? So you went, so messages, you mean is by the, it's a transport, transport. No, they're both, they both look suspiciously identical, but they are different, there are somewhat different in terms of how they, what they carry. So for instance, the message that you send has intent and a destination, like you are sending the message to someone for them to go and execute that trade. And you're interested in the result of that, in the result of that trade, while you send an event basically just as a fact of something that has happened. And those things are fundamentally different. And I have a section in my deck that I'm going to share in a second. I just need to go and learn how this works now over here. I think if we were to talk about that, we probably need to define it, define it clearly. So my, okay, my take of the message is, the event is going to be carried by some particle and then send it to some place. That's a message, but the message itself carries the event. So I have a pretty clear definition of these things in writing and index. So let me just go and share that quickly. I'll share that in the chat. Okay. So in this deck, I have the categorization from slide 21. Hold on a second, let me bring it up just a minute. And then. But I just want to clarify from a workflow's point of view. Actually, you know, only care for the event. Like, you know, only have event information. Like, you know, you need event identifier. That's it. The details, you know, the workflow doesn't define any event details. It just define what kind of event it is. Right? Yes, yes, yes, yes. The function that you want to trigger, it's just a reference to that event. That's it. The event detail will be defined in the events back. Yeah, so slide 22 is when that starts. And I think I have presented that. Hold on. Where are the slide numbers? Well, there is a, at the bottom, I think there's a selector thing. Yeah. Oh, I see. At the bottom of the page. I don't see a selector thing. Well, then click through. Yeah, I just don't know where to stop. Oh, there it is. Yeah, yeah. Okay, got it. And you, if you click in the middle, yeah, so that works too. It's like, so here, that's the section. Here, basically, so there's a word cloud in the prior slide and now I'm basically categorizing them. And then I split this up into the next slide is then there's intents and there's facts. Intents then work out that the messages facts are effectively events. And so the messaging deals with events and eventing deals with facts. And I can summarize that more succinctly in one slide. And I also have, and I'll share that also in the chat, something that's a little bit more product-focused and that's a blog article that basically summarizes the, summarizes that as the differentiation between messages and events. So I can go and turn it into one slide. So Clemens, I'm a little confused though. If you were to remove the, I wanna say semantics, that's probably not the right word though, but if you're removed sort of the purpose behind why some message exchange happened, what's the difference between messaging and eventing? You can't remove the semantics. The semantics actually matter because the, so if you are just telling a fact, you're effectively just reporting out an exhaust and you are not making anybody do work. If anybody needs to do work, that is you need to go and assign that message to a receiver and you also need to make sure that there's only one receiver that gets that data and handles that job, right? Or you have a message that transfers value in itself in the extreme case, Bitcoin, where you only have one processor which can go and put that into a ledger. These are all very different things from effectively just telling you that something has happened which is something that we can effectively broadcast to the world as much as you like. So these, from a, it's all the same, it's effectively the same mechanism, like it's the same protocols, it might even be the same schema, but there are significant differences in terms of the infrastructure that you need for those and how you approach it architecturally. So we don't have that defined or supposed to, okay. So for instance, let's briefly talk about while we're at it. Let's talk about the addressing discussion that we had, right? With events, what we currently do, we have this notion of source which really is it says this event is about this general scope or this general context, right? It's not really truly the source. The overall categorization, it's the topic even though that people have problems with that. But that's what source really means. There is no, nothing we have in the specification that says this is where this goes to. In messaging, it's different because there's actually a stress on where things go to because you care about a particular destination where things are heading. So in terms of eventing, you generally have a PubSub model. Well, in messaging, you generally have a routing model. Now, in messaging, you obviously also have PubSub infrastructure, but that PubSub infrastructure is not as, in eventing, you always have PubSub. You never have routing to a place and messaging can have both. Yeah, but, okay, I think I understand what you're saying. It's just, I'm kind of wondering within the context of the cloud events spec, why do people indeed understand the difference between two? Because in the example that Kathy gives, she has control transfers that are definitely not events. Like she's, so on her slide, on her slide that she has, when she goes into the state of now I'm buying and she's then emitting the control message, that the control message to function FN2, that is a control transfer. And you can only do this once because if you make this a PubSub thing and you make this an event of, oh, now I'm in the buying mood, then you can end subscribers and each of them are executing your trade and you certainly don't want that. Well, okay, maybe I'll just raise the question. So I understand what you said there and I understand that when someone is setting up their infrastructure, they need to understand there's between the two, but once you've decided, okay, I am going to send an event and cloud events looks like a good way to format or serialize my events. Does the split between messaging versus event thing come into play at all? Yes, because you're sending, you are sending to a particular executing party who ought to go and buy. Like you have one designated receiver. Whether you're choosing to decouple that in the infrastructure, that's a different story. By having a designated receiver that is a queue and then you have the actual receiver kind of encodes anonymously picking it up from that queue, but you have one place where the control transfer happens. That is not an event. And we don't have a mechanism to even express that in our spec, right? We can't say, and intentionally we can't say, this goes here. We simply say, this is this. So this is this event. We fully describe the event where it came from and what the type it is, but we don't have any notion of addressing in the cloud event spec. And for that transfer, you actually need to have a dressing. So here's my thought. I think from workflows point of view, I do not see there's a need to bring the messaging into the picture because that event, so let me clarify this. And so when that event one happens, that's a stock trade request, that's an event. And then the function one is going to go to the event, the payload or the event, how to say, the metadata event payload and see whether it's a buy or sell. And pass that information, which is part of that event. The event could have many information, right? The event payload, but it checked it out just pass that buy or sell information down to the next state and then down to the operation state. So there's no messaging involved here. See, this is where I disagree because eventing is inherently pops up and what you're doing here is not pops up. Sorry, what you're doing here is not pops up. You're doing control transfer. What you're doing in this on event, so event two is actually correct because you're observing the trader and the trader has now executed your trade. And the fact that the trade has executed is something that everybody can know about and everybody ought to know about because there's further activities that need to happen based on the trade having been executed because the trade execution then triggers the settlement of the trade on the other side of the world in addition to telling you that you now are about to own that stock. But the event one really is someone saying I want to go and buy something and that's not a pop-up thing. What that is is you are issuing a purchase order to a system that now needs to go and execute. So that is technically seen not an event. It might be expressible in the cloud events format but it's not an event because it's not a fact that has happened. It's a job that you're signing to a system to go and execute. No, okay, so I don't quite get what you mean but I think you know these are the events. So no matter whether the stock trade request or the managers or the customers say of confirm it's all come from the web. So for this stock trade system, right? The user entered on the website enter some information and then say, oh, I want to trade this stock. Yeah, but how often do you want to execute that trade? Oh, it depends. Whenever the user want to execute a trade operation. You click the button once and you say I want to have 100 units of this stock. How often do you want to buy 100 units of that stock with one button press? What do you mean? So, okay. Fill out the form. You fill out the form. You say I want to buy 100 units of this stock and you press the button once. How many units of that stock do you want to buy? 100. Okay, so then it pops up. It's not an event. It's not an event. Why is not an event? So it's like... Wait guys, can I make a suggestion? Because while this is a good discussion. Yes. I looked into the slide that we need to put together. I think it might be useful, Clemens, for you to write up what you want to say about messaging versus event thing. Okay, I will do that. And then we can have a discussion. Great, because so I think, so this slide is correct on event two and I actually like it in the way how it uses event two. I think the input to that workflow can't be an event because that's a job. And I think there's, if you differentiate out, there is actually a job that's being executed by the operation buy that then calls FN2. But then there might be also an event that's being raised by that fact that you can then have insights into the workflow state. So effectively monitoring of the workflow state is something that you would do with events but the control transfer into the execution you would do effectively with messaging. So I'll write this, let me write a longer comment to this slide and I'm also gonna make the slide for messaging versus eventing to go and clarify that hopefully. I have no objection to that slide per se. I just have objection to one of the arrows. Yeah, okay. I want to, I think probably we were not, I want to first make sure I think we're on the same page. Okay. So for this example, right? So from the user is going to define, this is like a stock trading platform or a stock trading application that supports the stock trade. It can receive the stock trade requests from different users from maybe hundreds of thousands of users, right? So whenever there's a user that says, okay, I want to do a stock trade, stock trade no matter it's 100 shares or 1,000 shares, right? That's an event coming into the system, the serverless platform. Okay. So that's the exact thing that I disagree with. It's not an event, it's a job. And that's- No, no, no, no, no. Okay. So from the serverless platform point of view, it is an event. No, it's not because you can't- Anything I receive from external, whether it's from like API gateway, it's HTTP event or from any storage as a storage event or from some messaging event. So here's the reason why I disagree. If you get the order to go and execute a trade, you only can do that execution once. And if that execution fails for some reason, you should go and basically put that job back into the queue and then retry. That's an operation that requires high reliability. That's not an event because an event is something that's like a photo. You send it and then you receive it, but once you have received it and you fail to execute that action, there's no way to go back. So that's why you need to have a messaging system and you need to have a queue to go and make sure that you really, really execute that job because it's controlled. So that's the platform's job, okay, not the event job. Okay, so the platform here, like for each state, for each function, if it fails, no matter if it's function one or function two, even the authentication, that could fail, right? Any function that could fail. There's a retry mechanism or there's a, in the workflow, if you go to the workflow, the user can specify the retry interval, the retry wait time and how many times it maximum retry. And then the platform will do that retry based on the users, whether the user can specify all these requirements. So it's not the event's system's job to do the retry because it's a service platform because that's a function execution. It has nothing to do with the event. Event is just an event, that's it. You receive it from how you are going to handle the event. The service platform is going to do it. So here's the second thing. If it's an event, it's available for subscription, right? Yeah, so the service platform was subscribed to that event. Okay, so I have- What happens if you have two subscribers? That's fine. The two subscribers get that event. However, those two subscribers is going to handle that event. That's not the event's business. It's a subscriber- But wait, but now you get one request that tells you to trade 100 shares. If you have two subscribers, you're now going to trade 200 shares. No, no, no, no, not. Oh, yes. That's not the way, okay. So you have one subscriber, you get that 100 shares, right? And then you know you get that. Another subscriber could be a monitoring or could be a statistic system, right? It's going to say, oh, okay. But how do you prevent, how do you prevent that you have two subscribers which both are able to execute trades which are then both observing that event? How do you prevent that? Because you're going to have a scalable system where you have many, many, many different nodes which all need to go and execute those trades. How do you realize that with an event system? You can't. You need to have a queue. No, so it's not the event job. Okay, it's a service platform. So when it scales out, right? It's going to make sure only, you know, one instance handles that, one workflow instance handles that trade, specific trade. If there's another trade from another user, it's another instance. And so you say, well, the platform handles it. And what I'm saying is the way how the platform will handle that is it's going to put a queue there because that's the only way how you can go and guarantee uniqueness. Oh yeah, yeah, the platform will have queue for sure. But that's the internal implementation. I don't think we need to, you know. And the reason, so because of that, it's no longer an event. It's a job message. Okay, so that's the platform's job. So how platform is going to implement, I mean, implement this, you know, workflow, the backend platform, how to export this workflow, how the platform implements that. I think that's the platform's job. That's the implementation issue. Either it's use a queue, what kind of queue, right? There's so many different types of queue, right, Kafka. All kinds of queue. So I think that's the implementation issue. I think here we do not need to get into the detail or into the implementation. There could be different types of implementation, different company will have different implementations. Here, I think we just talked about, you know, the spec, the high level. Yes, we do. I think we do. I think we do, right? So hold on a second. I think you want to say something. Yeah, I think I'm just saying the same thing. I think we do need to kind of think about how a platform would implement some of these things, defining it in a way which like, this is kind of one of the reasons I've actually honestly been backing out of like, some of the workflow meetings is because we kept on saying that, hey, we don't want to think about how a platform will implement it. I don't think like that's my interest area. I want to think about how platform will independent and like some of the ways we define it over here, if you define it as even, then I don't know how I've implemented as a platform. Okay, so how does the platform implement? I think that if people have interest, we can have another, whatever it is, we call it spec or whatever, or we can call it implementation. Then we can say how we implement this. But I think how you implement this, I don't think this should be a workflow standard, you know. But I have literally built systems like this, right? I have a background in financial systems. And I have been building workflow systems that provision stuff in Azure on very shaky ground in the beginning of the platform. Like I've been building, I don't know how many of these workflow systems. And there are two different flows of messages in those systems. There are messages and jobs that are being assigned to actors. And then there are events which are coming out of these actors as they have performed jobs. And the events will go and drive effectively the state system forward because these are things that have happened. But as you transfer control over, right? Into that workflow system. And as the workflow system transfers controls to execution of its steps, that is that those are job messages on those two things have different infrastructures today that people are using. And it's not something that you can just pump down to the bottom and say, oh, worry about that in the implementation because there are foundational differences. There is the event infrastructures exist and queues exist and Kafka exists because those all have very different reasons for existing. So the second, so before I have, I'm gonna write this up specifically to the slide but the second link that I sent into the chat where I'm explaining in a blog post why we have so many different messaging services in Azure basically goes and rationalizes that. What that does is, it basically explains along the side of, we have relay and we have event hubs and we have event group and we have service bus. If you go and take this as event group as the event router service bus as your message broker and event hubs as Kafka if you read it like this, I'm gonna give you, I'm giving you in that article the argument for why we need to have so many different services and why people use those. So the distinction between control flow and events is a very important one and it's realized in today's distributed systems architecture components that we're all using. So let me ask this, is this difference of opinion something we must resolve in order to produce the slides? It'd be nice, it's not required, like we're not gonna, we will do the talk. It's just that. Yeah, I don't think we have enough time to really resolve all this, you know. So here's what I'm thinking. So if you, okay, I think the messaging, the control flow itself, that's part of the service platforms job. I don't think it's an event specs job. I think for the event spec, we just, I think currently we have all those information. That's good. The event spec that we have does not have a two. It doesn't have a way to go and express, I'm gonna send this message to a particular party. It doesn't. Yeah, it doesn't, but I think that's a separate issue. I think, you know, how are you gonna send this event to a subscriber either it's a service platform or it's a monitoring system or whatever. I think that's another issue. I think we do not need to dive into that. We don't have correlation. We don't have a way to go and correlate the job that we send to the reply that comes back from that job. Like there's a bunch of constructs that we need for control transfer that we don't do here in eventing because we don't need them in eventing because we're just reporting on facts. But if you do control transfer where you literally go and take this state machine, right, is driving forward some state and now it's actually delegating out its own progress to an external party and it's waiting for the external party to do the work and until that external party has finished that job, there will be no progress. You literally take the logical thread of execution and delegate that out to someone else. You need to have a system that deals with that. You need to have timeouts, you need to have dead letter cues. I mean, there's all kinds of stuff that you need to make that control transfer work and we don't have that in eventing because we don't need that in eventing. But eventing is too primitive to deal with execution specifically in a financial scenario where you have stock execution. That's just not how the world works. So when you say that timeout retry is defined in the workflow, okay. When you talk, you've also mentioned about correlation, that's a very good point. So that's why I keep mentioning that. And also really to just have an event itself, you know, there's no, I mean, there's no real functionality. But to connect all this event and functions together, we need a correlation. That's also defined in the workflow. So probably because Clemente, you didn't join the workflow group discussion, you know. So you probably, you know, you miss some information. But I think that's part of the, you know, workflow spec. The user need to specify how you correlate these multiple events together because now they're, because now the functionality is, you know, we say introduction of service. The functionality is, is how to say decoupled between the service platform and the function developer. So they need to correlate. That's why they also need the workflows spec. But previously, right? Everything is done in one system by the application developer, by the stock trade application developer in his own system. Now, some part of the work like the workflow control, the scheduling of the resources, the retry and the correlation, all these are done by the platform. The application developer only do the function. That's it. So that's why the workflow spec to specify all this information. Kathy, you'd be super, super happy participating in the MQP working group because all the things that you need for your scenarios, what it sounds like is what we have in the MQP because that's where you're describing, you're really describing a messaging scenario and not an event scenario. And that's, and there's places for both. And this is why we have our feet in both of those areas. But the eventing scenario, you're overlaying a lot of complexity over the eventing scenario that is already solved in messaging infrastructures. You're adding, you're trying to add stuff to something that's ought to be something that's fairly simple and unifying across a ton of platforms by just delivering events and facts with effectively a correlated more control flow scenario that is the domain and the main domain of messaging. So, go ahead, Kathy. No, okay. I think I'm, you know, I think we can probably later, I think we can discuss more about this message, how that fit into the eventing. But at this stage, right? I think, you know, we probably, you know, I don't know whether it's good to bring this because there's people is going to be, it's not part of the events spec. It's not part of the workflows spec. I'm not sure whether that will confuse the audience rather than clarify more. Yeah, so what I'd like to suggest is this. You said that you would like to spend maybe one slide talking about events versus messaging. Yes. I think what would be good is for you to write up that one slide and then on next week's call for us to look it over and see how it feels. Okay, and I would appreciate if you would read that blog article, ignoring and Kathy too, and just ignore the fact that there are product names there because it's really a description of categories of products. Like, so service bus states since our message brokers and event hubs stands for kind of ingestors like Kafka and event grid is effectively what we're defining here. Then that will make sense. And this is basically just the product focus perspective on the classification of these different messaging systems. And I think that will help clarify that point. Okay, so yeah, if you can send me this link, you know, maybe doc, you know my email, if you can send it. I think we'll have it in the notes, do we? Yeah, but I will put it in the pop. You have it in the notes, that would be good. Okay, yeah, I will take a little bit, maybe. Yeah, because now it just pops up, so I don't know. Just from the Shanghai perspective, right? I think if we can talk about it, okay, we're working on workflow and we have some ideas. Like, I personally don't think we're at a point where we can say, hey, this is the thing and we've decided. But kind of bringing it up, so other people who might not agree with their ideas, get more engaged, that's good. Yeah. Yeah, I mean, it's all working progress. Yeah, sure. Actually, I think the purpose of presenting this is to elect more people to be involved on this. I think, you know, the workflow definitely is not the final draft there, but there are errors there. Even just kind version, I can see some errors there because different people are putting different sections, right? It's not coherent. And then I think we have more things to work on. Yeah, it's just a initial draft to bring people in, introduce the work we are doing. Yeah. Okay, so I think we might have beat this dead horse enough. So what if we do this? What if we all try to say that by next Thursday's phone call, we have all of our slides in there and ready for review? Because I know I have more that I need to put in as well, but I put in some, but not enough. But what if we shoot for next Thursday that'd be complete? Just to let you know, I have a jewelry duty for next week. Oh, no. So I'm going to check it Sunday to see whether, you know, I need it, but you know, I have whole week, you know. So that's why I think it's fine. If we need to reschedule, that's obviously fine, because it's obviously jewelry duties, that's something you can just avoid. But why don't we shoot for Thursday? And if you don't make it, then we can try to reschedule for some of the time, but at least everybody try to get their stuff done by Thursday and then we'll figure out when to meet after that. How's that? Yeah, that's fine. So if I'm on jewelry duty, you know, the whole week next week, the only time I can do it is Monday because Tuesday I'm going to fly, fly to China on a business trip and then later go to the Kupkan. So only Monday, November 5th. Oh, okay, I guess you mean the week after. Okay, got it. Okay. Yeah, because I hope next week I do not need to go to jewelry duty, but if I need to go, yeah, I cannot. Only it's Monday time. And there I'll be on plan, will be different time zone, will be hard. So, Cathy, Kupkan is the week of November 12th. Are you going there a week early? Yeah, so I'm flying over on November 6th, then the Tuesday, yeah. Okay, so Tuesday before the, so you're there for like two whole weeks then, okay. Two whole weeks, two and a half, yeah, two weeks. Okay, cool. Two and a half weeks basically, yeah. Okay. So, and that I will be on plans and in different, you know, cities. So it could be different, will be hard, different time zone. Yeah. Well, we'll figure it out. We'll work around your schedule. That's not a big deal. Okay. I also just pasted a link still that you might also add, which is the YouTube version of that slide deck that I gave you. Got it. Okay, hold on a sec. Copy link, let's go back to here. Okay, so it's in the, it's in the slide meeting minutes. If you guys want to take a look at that. Yeah, so that's from Vox Staffens and that's where I'm presenting a version of that spec a little bit earlier version of that spec, but I'm also going through all the, the differentiation. Okay. Sounds good. With more words than in the block article probably. Okay. Hold on a sec. Okay. Is there anything else you guys want to talk about relative to the presentation then? Not me. Okay, Kathy, anything? Yeah, that's pretty much it is. I am just interested to see, you know, this messaging thing because I'm not sure whether how that can link, but I guess it's okay, even when we are not quite, you know, connected very well each slide. I guess it's okay. This is anyway, it's a work in the progress. So probably not a really big deal. Okay. All right. In that case, I think we're done. And we'll talk next week. Unless Kathy's on jury duty, then we'll find it at the time. Okay. Doug, I've joined the previous meeting at 9.20. I don't know if account is in it or not. I put my name in there. You can see what you want to do with it. I will give you credit for it. Hold on, hold on, hold on, hold on. Okay, there you go. Just let you know, if I'm on jury, you know, for how will represent me in the next meeting? Okay, not a problem. Oh, another thing is when we were on CookCon, is there a still meeting or is it going to be canceled? Right? Oh, the week of CookCon? Yeah, we're definitely going to cancel. Yeah. Okay. Also the week before I have my business trip. Hold on a minute. Wait, wait, wait, wait, wait, Kathy, that is an excellent question. So hold on a minute. Maybe I will ask on next week's call. Cancel CookCon, call, CookCon calls. No, cancel the, can't say this. Even the week before, I don't know whether some people are already starting, start traveling. We'll figure it out. But it's definitely a good topic for next week's phone call to bring up and make sure everybody's on the same page. So thank you for reminding me. Okay, good. All right, cool. Anything else? That's it from my side. All right, cool. Thank you guys. We'll talk again next week. Okay. Okay. Bye. Bye.