 Okay. I think, you know, you're down with the roll call, right? Or you're like, okay, good. So it's okay. Thanks everyone for joining this meeting. I know it's for US people. This is the day before the holiday. It's good. I would like to post the link of this service. This one, no, not this one. The function graph, this work, flow language link. Let me post that to there. Okay. So that maybe I posted it here. I'm not sure, has anyone got a chance to look at this document? Anyone? Okay. It's fine. Yeah, I've reviewed it. So you have read it? Okay. Yeah. You have to read it. Okay. Good. Good. I think, you know, since this is the first meeting, it's open discussion. Okay. So this is what I put into the agenda. Like, you know, I'm thinking of, you know, we should define some use cases. And then we, I think another very important work item is to define the scope of the service workflow. And then we can define the goals of this, also the goals of the subgroup, right? What is output? And then we can dive into the detail of the, you know, how we should, you know, like, write the workflow specification, right? So I gave a draft there just to, you know, just to help with the discussion. So maybe first, okay, let's go to this document. So in this document, I have not written down any use cases yet. But I think we can start putting that down, you know, for the use cases. So what's the sort of other people? Any suggestion? Yeah. Hi. This is Tim Bray from AWS. Some use cases would be handy, very, very, very useful, I think in order, you know, to qualify what the effort is trying to achieve here. Also, I noticed that out there in the world of workflows, there are sort of generally speaking two approaches. There's the state machine specific approach, which, you know, which your draft seems to be taking. And there's the dependency graph approach, which is quite a different flavor, which is what, for example, Apache Airflow uses, which treats a workflow more or less like a make file, right? You say, you know, here's what I need. And to do that, I need these dependencies and those have those dependencies. And then the workflow system works through them. It's not instantly obvious, which, sorry, it seems clear to me that neither is universally the best solution, but they are well suited for different kinds of use cases. Right at the moment, Airflow is getting terrific traction out there in the ML community, who have to do, you know, ML people have to do a tremendous amount of file shuffling and processing and QA raising and so on. So I would think that, you know, I'll look at that. And then, you know, just a survey of the current state of the art, along with Airflow, there's Luigi, which is another, you know, popular open source, you know, generously licensed workflow system. And then there's a step functions, which is the one thing I work on at AWS. So yeah, I would think it might be interesting to, you know, contrast what's out there in the field and use that to figure out what, you know, unique purpose this effort is, purposes obviously this effort is trying to achieve. Yeah, yeah, I think, you know, I think that though, okay, those comes to the goals of the subgroup, right? What is a purpose, I mean, we work on this, right? So my take is we would like to define, I wouldn't say it's a standard, but it's a consistent way for the user to specify it's the workflow, the application workflow requirement so that no matter which somebody's platform, the user is, you know, it's using, it can be portable across different platforms. I'm not sure whether that that's other people's thought on that. Yeah, this is Brian from surplus. Yeah, I would agree with that. I would also say that one potential interesting angle to that might be the ability to be able to break up a workflow in such a way where parts of it can be spread to different systems, depending upon, you know, if the workflow reaches across multiple clouds, sometimes it can be beneficial to have a portion of the workflow much closer to the pieces that it's using before it goes back to orchestrate with the rest of it. It's just something to kind of consider there. Yeah, okay, that's good. I think that's also catch the, I think the, what's our goal, right? The goal is to have a doc. Let me edit that from, okay. I'm just writing down what's, I think that is that Brian, right? You say? Yeah. Sure, I mean, nothing wrong, but to be perfectly fair, you know, Apache Airflow can do that right now today, right? So. Yeah. I think, you know, that's a mechanism, right? So whether it's state machine or whatever mechanism, right? You know, the state machine can also do that. I think dependency graph, so we can discuss that. So I think Brian, you would like also to, space for, to add a word, say, you know, the workflow split up across different multiple clouds, how we do that, right? Yes, correct. That's what it said. Okay, not just in the, in addition to, okay. Addition to workflow in single. Okay, that's good. So the, okay, I think, I think this should be put this into the use cases. I think this is more on the, I would say this is more on a, on a goal, right? On a goal. Maybe I put this under the, under the goal. Okay, Mrs. So, okay. So I think, you know, maybe the first step is, you know, we add some use cases first to this document. No, not here. To this document, I already added a section on use cases. So anyone would like to add this. Any people would like to sign up for this? I can write some, add some. How about team? Would you like to add some? I'll have a look at the documents. Sorry, are you talking about use cases? Yeah. Sure. Okay. Anyone else would like to add, okay. Any other volunteers? Yeah, this is Farad. I could probably write a use case. Okay, good. Okay, good. Thank you. So let's go back to the gender here. So use cases. Now let's see. Okay. So the scope of the service workflow, which, you know, document here. This is kind of, not this here. This is, this is kind of like a scope. I can put into this as, you know, anyone would like to add, I mean, any comment on this? I see some, I think they should be out of scope for workflows. Which one are you referred to? The highlighted one? Oh, this one. What part should be used to correlate those events to the same function? Yeah, that's not about correlations, right? Oh, no, actually here should be, you know, actually in the work application workflow. So, so that's why, okay. For the, in the event, cloud events, we define some labels or some property values, some property or we can call it labels, right? But how they are used, I think, you know, they should be defined here. It's a workflow that, you know, which involves multiple events. That's going to be defined here. It's going to be defined here, like which label in that event property should be used to correlate, you know, all the events. Yeah. Events associated with the application together. So that's why I think, you know, we need to define it here. Because here is the, here is a place that's going to define, say, which label will be used for that complication workflow. Yeah, I'm disagreeing with that. I don't think we should pull that into workflow. So I think there's a bigger question here. Sorry guys, I joined a few minutes late. Like there is concept of workflow where something triggers a workflow which leads to different steps and different decision points and whatnot. But right now in this right up, we are combining a lot of things, which I feel is going to make it really difficult for us to actually make progress. So the two things which I particularly think we should pull out of this. One, we have this concept of events happening within the workflow and different parts of workflow depending on new events. In my mind, like an event should trigger a workflow, but then that workflow is kind of almost predefined. And then the correlation of new events happening, that's like another level of complication. So I wanna understand use cases, why we need to do this. In my mind, like the correlation thing and the new events happening, which the stages of workflow have to stop and depend on. Those two things can complicate this whole thing a lot. So I wanna understand why we wanna pull those two things in versus kind of go by, I'm taking Amazon as an example, right? So kind of what ASL supports right now, right? And not to kind of keep our scope to that much. Okay, so maybe I think I understand your key concerns. This will make the workflow complicated, right? I think how about we wait until the use case, right? You're, yeah, I can put in a use case for that. So you can see why we need this. Okay, and also I think your other comments as once we put some use case, we can see why we need it. Okay. I just wanna make sure I understand when it comes to the correlation aspect of it, is the reason that you think it's out of scope is because ultimately, if there's even if there is correlation done by the time the workflow gets invoked, it's sort of been collapsed down to almost like a single event at that point. And that's why we can leave the correlation bit as sort of out of scope for us. Yeah, I feel like either it's done or it's a responsibility of a function to do it. It's not a responsibility of a workflow to do it, is what I feel, but I could be wrong. I just feel like we're trying to solve kind of the correlation use case on the even side of things, which seems like the right place to do it rather than also do it in a workflow. Okay, thanks for clarifying. So let me clarify this, okay. I'm Chathura from WSO2. So I think, so from my perspective, I think it is better to have correlations because one use case would be if we knock a function within a workflow that replies asynchronously. So in that case, we have to receive the output from that function in a separate channel. So for that, we need correlations because we need to correlate that response back to the same instance of the workflow. Yeah, that's right. Support such situations, we need to have correlations. Yeah, so I think I'm, okay. So I think, you know, probably there's some, once at the use case, it's more clear why we need this. So for example, the user, if an application involves two events, right? Then, you know, we need to correlate these two events to the same workflow instance. So what kind of label to use to correlate those two events because there could be multiple instances of. Each event, each of the two events. So that's why we need to, in the workflow definition, if we need to have a place for the user to specify which label should be used to correlate those event instances to the same workflow instance. Does that make sense? Let me first add the, and then, you know, probably we can better see this. Cool, sorry, I'm sure you guys were trying to answer my question in my audio disconnected, but can't be the other use cases, I'll be great. Okay, good. Yeah, I think, I'm not sure who spoke before. Was that Shatura? Maybe you could add that into the document, you know, just to way of explanation of why you see the correlation is required. Yeah, sure, I agree with that. Great, thank you. Oh, so let's add the action item on doc. Let's see the scope of workflow here on correlation, make this decision. So action item, who's going to add? I'm Shatura, Shatura from the list. Would you like to write on there? I do not know how to spell our name there. It's C-H-A-T. I'm sorry. H-H-H-H-H-H-H-H-H-H-H-H-A-D, is that right? C-H-H-A-T-H-U-R-A. Okay, so you will add us... Use case for the correlation. Yeah, for why we need correlation in workflow. Okay, and I think I will also add one. Okay, good. So... Yeah, the second thing I had around scope and what we should pull in here, not right now, Cathy, your document talks about different step of the workflow being blocked on receiving new events. Like that's another thing I feel is like, we should think if we really want that in scope or not, but I'm concerned about that. Maybe... Let's just scroll down to your diagram below, right? I have a comment where you have step one happening and after that event one and two happen which leads to function one, but what if event one and two happen while we are on function step four? Like I feel we just kind of combining steps and function executions and decisions and new events. I'm not able to wrap my head around it. Okay, let me try to clarify this. So this diagram shows how user wants the workflow to execute, okay. So the user from this diagram, what it means the user wants to say, okay, in step one, it needs to, for this application, you need to wait for event one and event two to happen and then trigger function one, okay? Yeah. If event one, event two does not happen, the user does not want to execute any other function. Okay, that's what the user want, okay. Of course, the user can say, this is just an example. The user can also space that in step one, I just execute function one without any events. Just like in step two, there's no event trigger. The user just say, oh, once you go to the step two, just execute this function without waiting for any event. So this is an example. In any step, you can say you want the event trigger or you do not want event trigger. So that's not, yeah. I think that's what my higher level disagreement is. I think workflow should be even triggered but steps within the workflow should not be even triggered. Okay, that again goes back to the use case. Yeah, for that case, if you just say the first step, the workflow is event trigger, but the intermediates that do not need event trigger, I think we are restricting our code to restricting, very restricted to some use case. We cannot support some use cases. That's why let's see. Because in some use cases, for example, that just give me an example, like in a travel approval application, right? You first need the event is, okay, someone submit a travel request, right? That's one event. So you do some validation or whatever, right? And then later, you want to say, okay, if it's approved, then you want to receive approval event from another event. It's approval event. It's not travel request event. And then later you could also involve some, once approved, you are going to shop around for tickets, right? So then you need to receive another event. It's about ticket price from different airlines. So just for a travel application system, application system is not a complicated system. We can see it's already involved several events, a different step. Yeah, I mean, this has a distinct advantage in that you're able to coordinate events from multiple different sources that are required at different times within a single workflow. I mean, if you don't do that and you have to start up different workflows, then you have the overall problem of still managing that multiple workflows. Bringing them together into a single workflow with these steps is a distinct advantage here. Yeah, but like how, so when you say receive an event, how are we receiving events? Are we going to define that in this too? Like what is receiving an event to mean over here in this use case? Well, you define in particular something like maybe an event state, which I think is actually outlined later in the document where... No, but like, where is that even coming from, right? Like, am I like... Well, I mean, essentially, that's essentially no different from looking at a simple FAS function where you're receiving an event, you have to set up the mapping, the association between the event and the function. This would be done in a similar fashion. Yeah, but now you also have to do that to a workflow, not just to a function then. That's right, yeah. So the workflow, inside the workflow, right? There are many steps. Each step, it just like, you know, there's no difference from, you know, a single, a single, like, you know, event trigger or function, right? The event could come from different sources. It could be a storage event, it could be a messaging event, it could be, you know, a streaming event, yeah, any kinds of event. It just, you know, you call, with a workflow, you coordinate all these steps together because that's what application really involves. Yeah, I get it. I think I just think of some of the serverless workflows, again, kind of going back to Amazon Step Language and all like, how they're doing this versus the traditional workflows, the example you took off, the travel system and approval system. In my mind, I kind of like, think those two differently. I think I'm thinking more of orchestrating and changing a lot of functions rather than a traditional kind of workflow pipeline in my mind. And kind of if we take in these use cases of things being blocked on events, how long are the blocks long? Where are the events coming from? Like it does complicate our whole system quite a bit, but as I said, right? If we have use cases for those then, I guess we should. So I think just putting in those use cases will be helpful. Okay, good, sounds good, yeah. So I would like to clarify, it's not just a function, just a series of function. I think we need to have cover those use cases. Like I think I'm still not convinced whether going for this a lot more complex workflow system is more beneficial from what ASL is and why. Okay, I think we can let's document the use case. I think it's very beneficial because if we just, if we just say, okay, just a series of functions without any, we do not allow, in the middle of the steps, we do not allow the event to trigger. I think we are restricting ourselves to, well, it's good, quite some use cases. Kathy, I just want to make sure I understand, I apologize, I haven't had a chance to read the document yet, but in this particular picture, you branch and after step one, you do a branch to step two and step three. Does that branch happen before function one is finished or right after function one starts? After function one is finished. Because here it says function result, right? So that comes from the function one's result. Okay, yeah. Okay, thank you. Yeah, there's something that might be useful as part of this group would be helping to tie this into the cloud event specification itself so that we can understand, you know, for instance, how the HEP transport binding would trigger the workflow. Or in this particular case, because the fact that you have both functions and function response, as well as events being delivered to a function, it'd be pretty clear that there would need to be some consistency around how to be able to deal with responses, as well as what the kind of event delivery envelope is going to look like. So anyways, just calling out that I think there's some kind of lower level details here that we wanna make sure that we can connect the dots between what we've been working on and the system. Okay, so you're talking about, we would like to document how the function result will be handled, something like that, right? Yeah, exactly. Function result, yeah, that's, we will go, yeah, when we really dive into detail of defining all this, yeah, we're going to go to there, right. But yeah, that's a good comment. I think, you know, we are going to work on that. But first of all, so in here, I just gave up a very high level thing, you know, and then, you know, later we can dive into detail on defining all the different steps and the functions and how they relate to the event and function, yeah, sure. So, Kathia, if you consider the list of items that are in the top of the page. Top of the page, oh yeah, here. Yeah, don't we have to think of how are we going to, or whether we have to persist the state of the webflow in certain stages, because now I think we are talking about long running webflows, right? Because we are receiving units in the middle and so on. So there can be cases where the runtime may crash in between a webflow. And in such situations, we may need to persist the state or checkpoint the webflow and have the ability to restart it later. So do we? Yeah, yeah, is that the response? I don't think that should be part of the specification. Yeah, I was going to say the same thing. It seems like that's really implementation detail for whoever's implementing against this spec. I think the spec should outline basically how it receives the events for the workflow, how it interfaces with functions. But in terms of the inner workings of the workflow engine itself, it's really up to the implementation to kind of make the decisions around how it stores state, that kind of thing. Yeah, good enough. So maybe one thing we may need to consider, I'm not sure whether we have to consider, is do we need to define the points where the workaround needs to be persisted? Like usually in a traditional workflow, so we usually persist after receiving a message and so on. So do we have to define the spec that any implementer has to persist the webflow in these certain stages? Okay, so you say we need to define that the information, the event or the state will be persistent, something like that? Yeah, the stages in which the webflow state has to be persisted. State will be persistent? Okay, let's write it down with them. I'm not sure whether we have to consider so we can discuss that. Yeah, yeah. Do we define the state be consistent? Is that right? We need to define the stages where the state has to be persisted. Yeah, that state has to be, okay. I think you think persisted not consistent, right? Yeah, persisted. Oh, persisted, persisted, yeah, that's right. Okay, sorry. I'm sorry, yeah. Yeah, I think, you know, maybe we should, right? I want to be careful. I think maybe we should define or use cases and try and prioritize. Like I don't want to go and try and boil the ocean in the first go. It seems like we're taking on a lot but that's just maybe my engineer in me speaking and worried about kind of getting this done. Okay. It also seems like, you know, whether we're going to have to persist state depends on how we choose to model this, right? Because if you look at Kathy's graph there, the way she's laid it out, it definitely implies some sort of state. You could very easily rewrite this graph to make it look like every step is a completely independent function that's just waiting for a particular event to come in and whether that comes in as the output of another event or another step or whether it comes in just randomly on its own is irrelevant to the system, right? And in that particular model, you don't necessarily need quotes, right? So it depends on how we choose to model this and that's a very important design point we need to talk about. Yep. Like there is a concept of workflow but there's also a combination of like aggregation of let's say function and application. So they're two different things. Like workflow should really handle things that are kind of dependent on the actual workflow happening versus yeah, I have five applications they could get called with different events and I just wanna kind of keep that in mind, right? If step four only happens when even three comes through, like can that be some function? Does it need to be in a workflow? Maybe it does, but just think through that. I think we put all this function and application which involves these events and these functions together as a workflow has the advantage of you can orchestrate them and then together and then pass information together pass information between them. We can define all this in the workflow. So Kathy just on that point though I'd like to make sure I understand something scroll back down right there. So from step two to step four I see the step three, I'm sorry, step four has event three. I think to me the arrow is backwards, but okay. Step four gets invoked because of event three, right? Oh no, okay, let me clarify. Step four now, so step two when you come to step two you execute function two. After that you just go to step four and then when function five got invoked when event three happens. Right, but did event three come from step four and now what was the result? What was the result? Now let's do step four. The event is external event. So this event three could happen earlier, right? Any event could happen anytime during this step, right? But only when the step four, when you reach the step four, the user said only when you reach step four then that event will take effect. That event three will take effect and trigger function five. So what happens if you haven't reached step four but event three happens, it just falls on the floor and then it gets ignored? That's a good question. That's how you're implemented, right? That's the user. The user just say what is application once, right? But how you're going to support this? That's the- No, I don't think that's any longer implementation because that has a direct impact on how the workflow flows. No, okay, so let me clarify this, okay. I think from the users, so I think the workflow we want to define here is the workflow that user specify. It's desired workflow behavior, okay. It's not like how the system or the service platform should support this, support this. I think that let's separate these two. So one, so my goal of what I'm thinking here is we need to provide a mechanism for the user to define what he or she wants, okay. How the backend service platform is going to support this desired workflow? I think that's a separate thing. I think you are right. The backend service platform really need to consider how it should support it, right? For example, if the event comes early, how he should support it, how the platform will support it, right? But from the user's point of view, the user does not care how you are going to support it. The user doesn't care, say, okay, the event comes early, it comes late or whatever, right? Well, the user specify adjusts, okay. It just, the user just wants is when you reach the step four, which means function one has completed and then the result is function result one and then function two has completed. And then only when all this happened, I want function five to be triggered when event three comes. That's what the user wants, right? Yeah, but the user cares if the result ends up being different, right? So I think the specification does need to take care of, like our goal with all these specifications that we should be able to take our workflows from one provider to another. Now, if one provider is dropping even three and the other is not, that is having a big impact on the final result of the workflow that the user does care. Okay, so that means if one of the platforms drop even three, that means that platform is not supporting this workflow. That's the platform thought, right? So then back to Doug's question, then in the specification, we need to define what needs to be done to even three if it happens before step four, getting if you could or not, right? That needs to be in the specification. We can't just leave it for the providers. No, okay, I'm afraid I cannot agree with that because the thing is that why does, why we put the burden on the user? The user just say, okay, when event three happens, trigger function five. How are you going to handle event three? You're going to save it or you're going to throw away? That's the only- Kathy, the user's going to have to expect a consistent behavior. I mean, you know, so that regardless of where the, you know, what underlying system this workflow would be deployed on, there has to be a consistent behavior regardless of what underlying platform is. Yeah, I think I agree. It needs to, it's essentially boils down to whether it's a cute state machine or an uncute state machine, something of that sort. But I think that whether it's a cute or uncute, I think that's a backend invitation, right? I think, you know, for the, you from the user's point of view, so how you are going to say the user, why does the user need to care and say, oh, are you implementing this using a, you're Q8 or you're not Q8 or you throw it away? The user just say, okay, this is what I want. I want when the event three happens, instead of four, execute function five. Why does the user need to worry and say, oh, if event three comes early, how are you going to do it? You handle it. Yeah, because in one example, you threw it away. So the user does care, right? If it gets thrown away, then function five never gets executed. So the user does care. So I think, you know, actually implicitly, you know, this implicitly means if it comes early, you should not see sorry way. Because if a sort of way, right? Okay, so then we need to define what if it came two years earlier? Like we have to define some of those things in, that is how Mike, when I was thinking of this last night, this amount of complexity is what actually was making me feel like we should keep it simple and keep the events out. But if this group feels we need to take that in, I'm happy to go that route, but we need to define those things then. We need to define that in the specification. Okay, I think, you know, I think probably what we should say is, you know, all this event, if it comes early, it should not be thrown away because that's what the user want, right? Yeah, but that's not good enough, right? Like how much early? Like what if even three happened six months earlier and my workflow started now? Like if somewhere, somebody expecting now, expected to keep like that even three for six months, I'm assuming not. So I think we'll have to define those things if we go down this model. And I think related to that is, I think it might have been Brian was saying, you know, what gets passed between these various steps? So for example, the arrow between step two and step four, is that an event? Is it a cloud event? Is it something else? Okay, I think we need to define that next. A little piece here might be, again, if we're trying to define how steps actually tap into and wait for events, then part of that configuration could be actually responsible for configuring. Is it listening at the point of time that it reaches the step? Is it pulling from something that has an event log and it's just looking for the first event of this nature? I think there's a lot of different ways but we could specify it there in that kind of piece of the specification around how the step actually ties into the event source. Yep, agreed. And it's interesting to me is when you look at it as an event that gets sent from step two to step four, that's when I stopped looking at this as a grandiose workflow thing, even though we may have to. I look at it more as individual functions where there may be multiple events coming into each one. Yeah, exactly. I think the specification could potentially really drive to the heart of each, just focusing on the single step and then how we basically define the operation around those very small pieces. Exactly, and that's a much simpler model for me to wrap my head around, yes. So Doc, would you like to write that down? Sorry, I didn't cut, I was typing something else. Yeah, I'll make a note of that in the minutes. So let me put on Doc, Brian, you were discussing, I put something, say define how event is tied to a step. I think you two are talking about how the step, the interaction between the steps, right? Something like that. Yeah, I'll add some tips there. Okay, all right, define interaction between the steps. Is that right to do that? Do I catch? I'll expand on that while you keep moving forward. I'll add some more text. Okay, good. So let's see, any other, let's see, what's the time? Okay, we have time. I don't think that is, do we need to define the transaction models for workflows? Define transaction models for those workflows? Yeah, let's say that we need to make step two and step four atomic. So in that case, do we need to provide some way to make those two steps atomic? So atomic, you are saying, is that what? Like distributed transactions, things like that, do we need to do that? Yeah, yeah, yeah. Okay, let me write down, okay. Oh, sorry, I'm typing together, okay. So let Doc finish that. Doc, go ahead, you can start the next bullet, I'm finishing up. Okay, this is Chad, you were talking about Chad, Chad Thor, right? Yeah. Okay, so you're saying define what, define the, all right. Transaction models for the workflow. Pardon, sorry. Transactions. Transactions, transaction. Transactions for workflows. Transactions, okay, hold on. Transaction between steps, yeah, four steps. Four steps, step, atomic? Yeah. Okay, good. Maybe let's do not highlight it, don't upload it. Okay, good. So let's see, any other? I just could comment on the atomic one is I think like every function should be atomic. So I don't know if you need something special, but like I'm happy to look at a use case once in there. So I'm talking about function level, but I'm talking about multiple functions. Like for example, if you want to make a step two and a step four both atomic, that means either both has to be complete or not. Things like that. Okay, they should, again, I think we should be really careful about, I'm really worried this definition is gonna be something which is gonna go in the hall of fame and nobody's gonna implement it if you make it too complex. But we said to the hall of fame. In the never executed hall of fame. So I see, Doug, I see you're right, whether we can reduce the entire workflow into a set independent function course where they're kicked out based on the setup. But then that's not a workflow. Well, it depends on your point of view, right? You could break down the workflow into a set of independent steps or you could look at it as one gigantic thing. I think both are valid ways to look at it. We just need to decide which way we're gonna look at it. Yeah, but if you say it's a bring, break it into a set of independent steps, if there are multiple steps, then yes, it's still a workflow. So that's fine. But if you say just bring a break it up into just one step, then there's no workflow. That's my point. If you say break it into like, for example, you say, okay, step one, step two, step three, these three are one workflow and another is a step four or it's fine. But if you say just single step, then there's no workflow, right? You just have one step. No, but my point is you could model step four as part of a larger workflow or you can model step four as step four gets invoked when event three happens and when an event from step two happens. Oh, okay. That's what I meant. You could model it either way and you get the same result. It's just two different ways to look at the problem. So we need to decide which way we're gonna choose to look at it. Oh, okay, yeah, yeah, that's fine. Actually, I would say this is just an example. If you break them up, if the user want to break them up, that's fine. We just need to have a vehicle no matter what kind of workflow the user want to write. We can support it. Okay, that's up to the user. This is just an example. Another example could only have two steps. So I think that's fine if you mean that, you know. Maybe you want to clarify that a little bit more. No, so I'm reading this is in the, it just a set up independent function course. Sorry, go ahead. I was gonna have a second. I was gonna have a completely different question. Go ahead. Okay, how much have people on this group kind of looked at other people who are doing something similar in the industry, right? Like we're not the first one. While I don't want to kind of copy paste from others. I don't want, I want to at least get influence and see what's been working out there and what's not working out there. I've only looked at ASL. So like I ended up mentioning that a couple of times. I don't know, Cathy, if you've kind of got a chance to look at the other models that exist in the world, especially kind of focused on serverless workloads. Yeah, I have looked at, you know, the AWS staff function Microsoft Azure, I think it called application logic. And also we have, you know, I think there are another platform now and something. And that, yeah. So one of the things we did when we first started the serverless working group itself, when we put together that white paper was basically talked about what's currently out there in the industry today. And so Varun, I think you have a very good point there. Maybe it would make sense to have people give very quick presentations of what's out there today. So if everybody's on the same page about current state of the art. Yeah, and obviously I think that presentation or whatever it is should focus on why or what things, some of those existing stuff are not able to handle well and how we're trying to actually handle that differently or better. Yeah, cause one of the questions we should ask ourselves is as part of this exercise, are we really interested in solving a problem that no one has solved yet? Or are we simply interested in trying to find some harmonization or inter-operability around existing solved problems? Cause I would think it's more the latter. Yeah, that's right. I think it's the latter. I don't think, you know, like, you know, the problem are not solved by solving something on, you know, no one has ever solved, right? I think we're trying to come up with a common model that can be, you know, not just portable across all different platforms. For example, on step function support, similar functionality on AWS, no Microsoft Azure, also similar. And yeah, so. It might be useful to have a presentation on maybe the three or four most popular platforms out there to see what features they support and so we can determine what's common across all of them to say those are probably the subset of things we should focus on. All we can say it's not necessarily a subset. It's just some function, some set, which, you know, can support all these use cases which can be portable across. Because if you want to find out, you know, not every platform support is exactly the same way, but we found some common things, you know? And then. I also think that we can also think about how we differentiate function workflows from traditional workflows. Because if you take traditional workflows such as BPMN and so on. So what are the differences are we going to have in here compared to them? So that will make us easy to understand it. Understand what we are going to do here. So maybe I think, you know, we can. So for this, I was thinking, you know, people, if you can add comments in here and then so we can improve this document, that would be good. That would be the next step. You can also feel free to add modifier section or add any new section which you need. Does that sound good? Yep. Okay, good. I think it would be useful to schedule time on next week's phone call for people to give very short presentations on what some of the current providers support. Okay. Or do you want people to do that, you know, in their own time? What do you mean by in their own time? Well, do you want people to go off and do the investigation on their own? Do you see what people, see what platform support or do you want them to give presentations on this phone call next week? Yeah, I think you know, let's give presentation on the phone call next week. So who would like to, let's just decide who would like to give a presentation. So anyone would like to give a presentation is there like people there who would like to give a presentation? Do we have Microsoft people on the call? I don't see Microsoft, I don't think so. There's no one there. So let's, I can give a presentation on, you know, how Huawei's service platform solve this problem. I can reach out to somebody on the IBM side to talk about what OpenWISC supports. Okay. I'll try to get them to show up on the call. Okay. We had WSO to also developing a programming language called Ballerina. So within that also, we are supporting workflows, but that is ongoing work. So I can also give a presentation on that. Okay. Okay, I think, I just visited people, can I see? And then IBM, you say, dog, who, who will be? I'll try to find the appropriate person who is more of an expert than I am on it. Okay. So I just write your name there, okay? That's fine. Who else? I'm Chaturth from WSO. Okay. So Cathy, which topic are you gonna be talking about? I'm talking about is a Huawei's service solution called Function Graph. Yeah. I can just go one way. Function Graph, it's called Function Graph. Let me write it down. Good. Yeah. OpenWISC and chat. What's your, what's the solution? I'm talking about Ballerina, Ballerina language. Sorry, maybe you want to write it down? I can write it down. Okay, good. I would also present, maybe someone can present AWS. Anyone right here? We could probably get Tim to do it. Tim? But he had a job from the phone call, but we can probably volunteer him. We just put it in here, okay? Sure. That's what we do to anybody who drops off. Yeah. Okay, good. And somebody for Logic Apps too, I think I don't know if somebody from Microsoft is gonna be part of these conversations or not. Oh, we can present. We can help. Someone volunteer to present. You can just look into the Microsoft and then see how, yeah. Whoever want to volunteer to present this, Logic Apps. Anyone? Yeah, I'm just not sure if I'm gonna be here. Like I might have a conflict next week if I'm not gonna volunteer. Anyone there would like to volunteer for the Logic Apps? Okay. I think we need to get Clemens to come do it. Yeah, we can get someone too. Okay, maybe someone can add his name there. Okay, that's fine. That's good. So we have, I think we have enough people to do the presentation. So next, let's do the presentation. And then we can add the use case. I think that's good. We have five more minutes. Any other suggestion? So here I have a comment saying, is it not solutions, new problems? That depends on how we define the new problems, you know, if it's just some workflow-related issue, right? Because different platform address could solve, the scope is different. Cool, Cathy, are we doing attendance in these meetings? I joined 10 minutes late. I don't know if we're doing attendance or not. Yeah, we are. So let's put it in. What's your name again? Yeah, that's me, yeah. Thanks. Your name is there, right? Okay, good. So let's see. Okay. Reduce the entire workflow, independent function calls into a setup. So dog, I think he or you know, is a reducing our flow into a setup independent function calls. What do you mean by that? Well, let's go back to what I was saying earlier. If you look at each step in your example, you could look at it as a set of independent function calls where they're invoked based upon one or more incoming events. Yeah, but are you talking about into a setup in the, okay, a setup independent function calls steps. So you're not talking about one step, right? You just trying to say a set of steps, right? Well, I could hear a very place calls with steps. Yeah, that would be good. Okay, otherwise it's a bit, okay. Okay. And... Can I say no, he don't... Someone speaking? Yeah, can I say no, he don't, can you hear me? Sorry, I said a bit low. Can you hear me? Yeah, okay, could you try again? Yes, I'd like to do one comment. In the beginning of this meeting, there is one comment. Someone said there is two approach it. One is state machine, the other is mega thing graph. I think we need to more understand the difference between state machine approach and mega thing graph approach. As far as I know, I don't see any differences. Sorry, I have a hard time, you know, understanding. Could you speak up a little bit more? Yes, I think my comment is that, I think we need a common understanding of the difference between state machine approach and the mega thing graph approach because I don't see any difference because the state machine has a mega thing graph. So I think we need a common understanding in this particular difference between the two approaches. So the difference of this approach, of these two, right? You don't see much difference, right? Yes. Okay. If I can, it seems like the state machine approach is pretty explicit about here, then there, then there. Whereas the dependency graph, you say, this is what I want and then it's up to the system to figure out what the state machine is to achieve that dependency graph. Yeah. As far as I know, I think Apache Airflow, they say using the mega thing graph approach, but it seems to me, I couldn't understand the difference. So you said the state machine was explicit of the state. So he's saying, okay, he said dependency graph creates a state machine implicitly based on declared dependencies, something like that. Okay. I think even, I guess, you know, as far as you know, you know, AWS step function use a state machine way to do it. I feel that, I feel state machine is more straightforward way to do it. And also Huawei's function graph is also that way. I think the logic apps is also similar way. But anyone would like to draft? Who is that? Just speak, who, what's your name? Who just spoke? Sorry. This is Evan Anderson at Google. Oh yeah, Evan, yeah, before you. Who is? I'm no hero. Pardon? I'm no hero, music, okay, music. Maybe you want to add, is that how to spell your name? Maybe you want to add your name there? NAO, H-I-R-O. Sorry, no hero, I'm just speaking for you, so. NAO, H-I-R-O. Okay, thank you. Now it's much better. Okay, always. Okay, good, thank you. I think we're running out of time, that's good. So we're going to continue our discussion next week, next Tuesday, we're going to do, I think we're going to do the presentation on each solution. That's all. Any more comments or questions? Nope? Okay, thank you very much. Let's, you know, meet again. So I'll be happy for a long time. Okay, thank you, thank you, bye.