 Good. I think we can start now as other people can try later. So today, so let me first share the agenda. I think first I'm thinking I'd like to go through the use case discussion. I think some of people already put some use cases in the document. And then we're going to have a presentation of existing offerings and features. This is the action item from last meeting. And then we can go through some review comments on the proposal document. I saw some people putting the review comments. We can go through that. And so any other thing you would like to add to today's discussion? Or does this sound good? Okay. If no. This is good for me. Okay. Great. Good. Thank you. So let me first go through the use cases. I think, you know, so we have several people put in. So these people putting some use case. So first, this use case, I'm putting this use case. I'm going to go through it. It's like home monitoring use case. I think, you know, the purpose of we go through the use case is to one purpose is to address a comment, say whether we need an event state. Okay. So for this use case, let me try to go. So use this diagram. Probably it's easier to go through it. Can you can you see this document? This diagram clearly? I can. And then it also pulls up in the, like I went to the document also on my own computer. So I can see both. I don't know whatever else is doing. Yeah, I can see it. Okay. Okay. Good. If you can see. Okay. Let me see whether this will make it larger. View is a view. Yeah. Oh, I think it's already view 100. Maybe 125. Okay. Maybe this is better. Okay. So, so this diagram shows it's a home monitoring system. Of course, you know, this is just, you know, not, you know, every detail of the home monitoring system that different types, but this is just home monitoring application. So at the beginning on, there will be this, you know, enter this state. So there will be three. Okay. So maybe let me go first goes through this, the event. So they are door opening this application. So that's it before windows state one state one like a waiting state waiting for an event to happen. No, it's not a waiting state for even to happen. Basically, you know, the first event, no matter is event is a door open or motion detection event, that will trigger the function, the workflow to start any of these two events. So the first event, first state actually is an event state because it's waiting for an event, but any event comes, then, you know, it's going to start the workflow and the entry. So either even one or even two is going to trigger state one. Yeah, it's going to trigger one. That's right. Okay. So it's drawn this way. But so the other I think that people draw another way. So there's a start, you know, it's not a state, but, you know, there's a start, start, start, how to say it, starting point. And then the first event comes, it's an event state. Okay, so I draw this way, I guess different people draw differently. This is just representation issue. So what I mean is, you know, in this state, when the event one or even two counts, any of this event comes, it's going to transition to the next state. Okay. So in state one, so when any of the event comes, the workflow starts, and then, you know, if it's still open event, it's going to transition to the next state. If it's a motion event, it's going to transition to it's going to, okay, to trigger. So this event will trigger a function called face recognition function to recognize. So state one is actually some kind of a decision state then. State one is kind of like, so that means in state one, you can receive multiple events. Yeah, it's also deciding the next part of where we should go, right? Exactly. Exactly. Because that's the application month, right? And so the application, you know, this application home monitoring, you know, you could receive a door open first, and then later, a motion detection, or you could receive a motion detection sensor event first, and then later, a door open event, right? So it depends on the scenario. So that's why in order to handle this scenario, this state needs to be able to, you know, to accept, you know, multiple events, and then different events could branch out to different next state, as you just mentioned. Yeah. So if it's, so let's go through, if it's door open event, it's going to transition to state two. If it's a motion event, it's going to first trigger a function for face recognition to recognize whether it's family member or not family member, right? If it's a family member, so of course, that's the result of the function one, this service function. If it's a family member, everything fine, you know, there's no, this is a false alarm. If it's not a family member, then transition to the next state, which I give it in a state four, okay? So, and then, you know, in state four, you know, it's going to here, it's going to wait for another event to see whether there's a door open event or window open event. I simplified a little bit in here. I didn't mention the window open event because it's similar to door open event. So it's going to wait for another event. So if this event happens, okay, if there's, you know, it's not family member, and then the door was, the front door was open, then, you know, it's most probably it could be a burglary and broke into the, and breaks into the house, right? And then so there will be, it's going to trigger another function. So this event is going to trigger a function, second function, which will send a message to the two contacts on the file. Okay, so whatever, every home you can, you know, you can put in two contacts. Okay, so now let's stop here. I'm going to go to the left side. Yeah, so if you are in state four and you wait for an event to happen, how long are you expecting this to wait there? Okay, that's a very good question. So there should be, okay, so there should be a timeout value there. That's how, I think you already come into how we are going to design it to support this, right? So that's very good, you know, there should be a timeout because if it's long time between the gap, right, it doesn't necessarily mean it's a burglary, right? So for this application, yeah, there should be a timeout here, okay? So let me stop. This side, I'll go to the left side. If it's a door open event, there's no function to trigger to processing it. It just goes to state two. In state two, it's going to wait for another event, which is a motion detection event. Again, there should be a timeout, value associated with this, you know, this state. And then, you know, when they get a motion on detection event, it's going to same thing. So the door is going to do a face recognition. If it's family member, that's fine, you know, the family member opens the front door, that's okay. If it's not family member, then it's going to go to state three. So at state three, also two events already happened. One is door open, the other is motion. And then same thing, it could be a burglar breaking into the house. So it's going to send a trigger or a second serverless function, send the message to the contacts on the file. So these two, so now we come to either state three or state four. Of course, only in the reality, only one pass will happen, right? But no matter which pass happened, so when we come to here, so now we'll wait for the response, because we send, so this function two already send a text message and email to the contacts. And then we come to state five, state five has to wait for another external event, which is a response from the, from the two contacts. So if suppose, say there's a response, then you know, it's going to do automatic language processing, say what kind of response it is. Is it okay response or not okay? Because when this message send, it's going to send together with the image too. You know, it's not family member, but send the image. And then if the response say, oh, it's okay. Everything fine. It's a false alarm. If it says not okay, then it's going to trigger a notification message to the police department, to you know, all those emergency department. Okay. And then now come back to state five. So in here, if they time out suppose, and here you start a timer, right? If it time out, it's going to automatically call. That means there's no response from the, from the two contacts. There's no text response or email response. Then it's going to call, automatically dial the number to call the, the contact. And then if the contact response say okay, so not okay. So then, you know, it goes through the same process. I simplify a little bit on the whole because our purpose is not to really, you know, design a home monitoring system. I just use this home monitoring application as a use case. So when they need to migrate to serverless platform, right? So what they could, you know, what we need to support the whole workflow. So we, I think we already see that we need the event state because there are several states that, you know, wait for external event. Also, we need to support that time out in that state if we wait for an event, right? There's also, actually it also shows we need to call it this event because a door open and the motion detection. We need to know they come from the same house. Otherwise, you cannot say, you cannot say, okay, door open from, you know, for example, Rachel's house to a motion detection event coming from Kathy's house. That's not right. So, so here I think we already derive some requirements say we need to support event state. We need to support, you know, the, what's that? The time in the timer in the, in that state. Also, we need to support the correlation between, you know, all these events. And I think, you know, in real serverless, when we spend the serverless platform really start to support serverless application, it's not just a single event trigger, a single function. It's not that simple. Actually, quite some application involves multiple events and also multiple functions too. Yeah. So here we have several functions, you know, we have one, two, three, four, five functions. And then we have multiple steps. We can model these as, you know, different states. Yeah. So this is this use case. Any questions? So if not, let's go to the next, next use case. I think we'll put this in for hard, right? You put this in for hard online. Yeah, yeah, I'm online. Sorry, I was on mute. Yeah. Can you guys hear me? Yeah, I can hear you. We can hear you. Yes. I went ahead and put a couple of use cases there. In general, they are far more simpler than what Cathy just went through. So, and you know, they're not the complete details. It's just the basic cases that you would, that can be used to implement the base, for example, case one. It's a basic loan approval process. Of course, you can add far more complexity to it. No, I think here this is a video, right? Oh, I think you, you probably messed up the loan approval with the video. Go down. I think it's gone upside down or what? Oh, I think you, you have this video, right? This is a video. I think you attached a wrong diagram because here it shows it's a video, video metadata. All right, sorry. So let's go down to the second one. I'll correct that. Okay. So let's say this is for a basic employee travel booking. We all booked tickets, airline tickets from, from our employers. So this is what it would look like. The first thing is the employer goes, the employee goes, sorry, a little bit higher. Up there you go. The employee goes. Oh, sorry. Yeah, I know. I'm trying. Go ahead for her. Sorry. So event one is the employee goes, he submits a form, books a ticket, the form will be entered either in a storage or in a database. Once they, that's, that's what's shown in the diagram as event one. Once event one happens, state one will go execute the basic function one, which is, you know, call it a travel validation function. This will essentially check the employer, employee's current status, employed, not employed, current grade, in case the, in case the employer has limits on grade, like some employers do, some don't. After he does the basic travel validation, he'll go to state two, up in state two, basically, and after the validation, if the validation succeeds, an email will be sent to the, to the employee's manager. It's all part of the function one, the travel validation function. After it does send the email or whatever notification, etc., the workflow transitions to state two. It stays there until and, until and unless the manager basically approves or rejects it. And as someone just said, yes, there'll be a timeout. There'll always be a default timeout. If, if the manager doesn't respond, in this case, I would assume you can probably set a longer timeout, 24 hours, 48 hours. If not, the workflow is ended. The thing is canceled. If the manager respond, you can make it more complex. You can escalate the issue to a high-level manager, etc., etc. Let's take this simple case, the manager approves or disapproves. As soon as the event comes, state two will transition to the next state. I've called it an approved state. I could as well have called it just a state three, state four. In the approved state, it's essentially a, you are checking for the results of the event. Event two, if it's a yes, then you transition to state three. If it's a no, that's it. The approval of the employee travel request was not granted. It ends. Once you move to state three, the next thing is you essentially, just like AWS, start multiple parallel functions, you basically check the price for a line A, a line B, etc. After you get all the, all the responses back, you transition to state four. In state four, you essentially compare the function, not necessarily for price. You compare for time. You compare for, you know, all other factors, whatever your business logic is. After you do that, you finally figure out which, which line you're going to book at. You move to state five and in F5, you finally go ahead, you do the actual booking and that's where the workflow ends. You know, just an exemplary workflow that I'm trying to illustrate for the case of serverless workflows. Any questions? Yeah, I think I'm still not able to wrap my head around that same question. When we start having states that waiting for another function to come in, that's the equivalent of me running a service, waiting for a request to come in. It's completely beats the concept of serverless, right? Why can't we have this with you? Sorry, you mean waiting for an event to come in? I thought I heard you say waiting for a function to come in. Yeah, waiting for like the manager approval over here. Sorry. Yes. So we can have a function which is basically approve, sorry, to create a ticket. So book a ticket, somebody does that and that creates clicks of validation. That's great. And then they sense another calls another function to send an email to a manager. And that's where the workflow ends. Now, when the manager, when the manager approves another workflow kicks in, like this workflow waiting for the manager approval to come in that in my mind is becoming traditional application is no longer serverless. It is actually serverless because nothing is running. There's no thread or anything running. No, but you are in a wait state, right? How is your workflow still in a wait state? Well, that's the beauty of the implementation. There are multiple ways to do it. If you do it using Golan, using thread, your thread will be waiting. That's one way to do it. That explains your explanation. The other way is you basically save the state to a database. And basically at that point, just wait. And when the thread kicks in from whatever correlation you get, you get it from the database that but those are the implementation. There doesn't have to be a line between state one state two separate workflows, right? Why even we thinking of it as single workflow then? So the whole point of this is so what you are suggesting is what AWS does it's basically you break a workflow into multiple into multiple step functions. And you are basically interconnecting the step functions using essentially lambda functions. So that's one way to look at it. I think a more with that if you have to troubleshoot it, hey, it's like you have a workflow consisting of let's AWS has some examples, you have something like seven, eight different step step functions, all of them interconnected using lambda functions. If you have to start troubleshooting, hey, workflow one is currently in step function three, and it is stuck in function four, would that be easier? And remember that itself that workflow itself will scale. So you could have 10 instances of a workflow. Instance one is run currently running step function three, it's stuck in the middle of function three. Whereas here right now, every workflow, that's it, it's its own self contained instance. If you need to troubleshoot this, hey, the first instance of this workflow is currently stuck in state two, we need to troubleshoot that. Which one do you think would be easier? I think this will be more difficult. The reason is because we're going to have so many workflows stuck in different states, and then we're going to get a manager response, we have to make sure this manager response is going to go unlock this workflow, like there's going to be a lot of correlation, a lot of state keeping that will need to happen in this case, right? Like I mean, then we need to back up the state we need to do like, this is going to be so much more complex than just I disagree entirely with that. From the user's perspective, if you have a single workflow with all that encapsulated with that single workflow, as shown here, it becomes much simpler in terms of usability. You're dealing with a single workflow and managing it. The implementation at the back has to deal with that, but that's not the user's perspective. We're intending to bring interoperability here between users and allow them to have a create a workflow that can be easily visualized and managed. If you've got coordinated step function makes it much more difficult. You guys can keep talking if you want to give me a clarification. What do you mean by user? Is it like an end user or are you thinking of a developer as a user? Yeah, it would be the developer. Okay, so for a developer, I think this is going to be a lot more complex because now you have these different states which are wait states. So I have this is going to leak into so many of my workflows that are open and that I need to have something that's going to go clean out these states which are timed out. It's going to be a lot more difficult to debug in my mind because we're just leaving workflows in wait states all over the place waiting for functions and somebody when an event comes we need to know is this even going to trigger a new function or this is going to go continue an existing workflow. Like it's a lot more complexity I think. So Maroon, I think you are mixing the user's perspective with the back end implementation. I think all those complications you mentioned is the back end implementation. It's not the user perspective. From the user perspective you only need to draw this workflow just one workflow but your back end need to take care of you know when to you know like you know to move to the next state like how to correlate you know this event. That's your back end. It's not the user. Your user doesn't care how you do it right? Understood. How you're going to implement the workflow? Understood. So let's do it. If we mix the user's perspective of the you know the user's interface with the back end implementation you know then you know you are going to I think that's not right. The back end you know you can do whatever way you like right. There could be you know simple implementation or there could be complicated implementation but that's not you know I think what we we will really you know address a lot here but from the user's perspective he just need to you know to specify this one workflow instead of specify you know multiple workflows. That's all users need to do. User doesn't care how you are going to you know transition to how you are going to implement this right. Like you said you know how you correlate all these events together how you scale out. Also now come back to the implementation point of view. So let's just say okay from user interview is one workflow multiple workflows then the user need to configure multiple workflows and they need to configure how these workflows you know associate together because they all belong to the same tribal request right. The user need to make sure how they configure this to make sure these you know all these different workflows actually you know I'm used to for the same tribal request. So I think it's more complicated rather than just one workflow from user's perspective. You're absolutely right. I think I'm thinking definitely more from how I'm going to make sure once we define this language how are we going to make sure that people will be able to actually adhere to it and implement it. So you guys are right I think from a developer who's using a service that is following this language it's definitely easy but I'm really worried that people will not be able to implement this well and that might lead to a bad experience. So yeah you guys are right I'm thinking from a different perspective. Okay great so now we can talk about how the back end should implement it of course I think different companies is going to implement it different way right but you know actually it's not really complicated as you thought and if you really think through it actually there are ways to make it simple. So I think you know one thing you know you mentioned say the but I think probably we can postpone that discussion to later stage when we go through this you know but I guess if you think about the implementation actually if we look at the current work floor and times like BPM and so on then they also implement similar things so I think we can someone who is going to implement can get influenced from those things I said. Sorry which one did you mention? So you are concerned about the implementation complexity right? Yeah nobody said somebody does it I don't know I didn't get the name. Sorry? I thought you mentioned that somebody does this today I didn't get the name. If you look at the current traditional work floor engines like for example activity of those things also do the same thing so yeah but that's not serverless right that's not what we're going to build so yeah it's not serverless yeah but if you look at common server now they are pitching the test as serverless as well so actually they are also building a similar thing to serverless work floors. So I think we'll go through the current who is speaking. Sure we can we can go through that. Yeah I think yeah I think sorry who your name please who was speaking. Okay yeah I think your point is you know there are existing ways to support this right to implement this right that's your point right. Okay good I think you know we need to write some meeting minutes for this discussion because I think the the questions asked are the people could have the same questions right and then we clarified and then we talked about this so let me write some meeting minutes okay so here home monitoring case stay where we see multiple events of the move which they go to okay I think um so we're room right is that you will ask a question yes that was me yeah sorry I spoke by your name correctly um we are you close enough yes okay it was complicated or you think it is complicated and but actually I think okay so there's just a point I'd like to add for this complicated thing I mean so as someone who's worked on AWS extensively even though AWS right now the step functions doesn't provide event support if you go inside the message boards and if you look inside the customer requests customers are requesting that we want events to be supported with step function for that and AWS's response is we don't comment on current things so just to just to keep that in perspective that customers do want to support that's that's one thing we what I was looking at and when we found out the limitations. I'm not surprised at all but there's a reason that AWS did not introduce it in the first version and that is what my point is like serverless will not solve everything in the world and we should not try and boil the ocean that's my biggest concern right we're going to come up with this thing that's going to be difficult for uh companies to implement and you'll have a spec and people not going to use that spec like I don't want to end up at that point like that's my only thing I just wanted to yeah so I'm going to add that later more and then I think uh who speak what your name please how do you spell your would you like to put your comment you say they are existing right I would yeah maybe would you want to put your name there yeah okay good um c h a d h u r a c h a oh i know okay all right yeah okay yes good on so now let's go back to um maybe someone would help if can help write this meeting minutes a little bit that would be good um so so this is one work first so we clarify this right and then I think you're agreed but we'd like to know how back and okay good let's go so I have a bit more fundamental question so that is what is the purpose of this that means sorry no this this is not so my question is that uh so what is the main purpose that we are trying to address with this uh are we going to create something that can orchestrate my serverless functions so this runtime itself has to run as a serverless so you're saying what are we trying to address here yes that means do we want to create something that can orchestrate serverless functions or the runtime that implements this workflow also should run as a serverless no I don't think it needs to and I get I know what I know where you're getting to I don't think this this workflow implemented needs to be serverless okay okay so then then what are the main differences of this approach that we are trying to build and current so so let me try to address this functions are serverless functions I would assume all the functions are serverless functions yeah yeah they are in the diagram that I have f1 f2 f3 these are all serverless functions it's just it's no different than it's no different than amazon step functions your workflow runs and then the workflow calls functions the functions are serverless functions yes but the web for runtime itself is not serverless right that depends on the implementation in general it probably won't be because it needs to maintain state so in general not but it depends on your implementation if you use a data maze yeah I guess it could be serverless sure okay so if you ask someone at amazon it's like if you ask someone at aws how does your step functions run as your step functions itself serverless or do you guys it's I would assume that's an implementation dependent question so then if you take a normal workflow engine so it can also knock out service functions right absolutely correct yes so in that case what is the main difference between this approach and normal web for engine it's like what's the difference between the aws step functions and what they had before that so the whole point is you can basically sequence you can sequence you can sequence functions one after the other with logic in between and the workflow manages the sequencing around with the logic one clear differentiator I think might also be how this ties into cloud events I think it'd be really important for us to be able to lay out exactly how this workflow engine is closely tied to the cloud event signature and kind of all the delivery of potential delivery endpoints of events so how the workflow tied to events right specifically cloud events is that who is talking please it's brian oh brian okay okay let's clarify this I think you know so the I think these are the workflow serverless um I think I see comments that you know these functions are serverless and this workflow which orchestrate this function could be serverless too right but there's an explicit requirement for them to be I mean these functions could technically be h&p endpoints I mean an event underneath the cloud events definition yeah you can deliver an event to anything anything that implements the cloud events uh transport specs and I think that's something again when we think about this I think it's worth considering that um in terms of the API so we find how does that again adhere to the cloud events orientation so brian sorry go ahead go ahead so brian if I understand what you're saying is let's say what's in the diagram you're saying function f2 could be translated to a cloud event that could run in a different cloud is my understanding correct yes correct so you can imagine that so that the function itself implements the cloud events um h&p transports right and so therefore by implementing that anything doesn't matter what it is could be to be considered a function this perfect absolutely by not I would say yes yeah so what maybe for her would you like to put that you know comments in the meeting minutes yeah brian simply okay go ahead go ahead yeah I could see that cloud events could actually be what is passed between each state uh what is brought in through the events you know like event one event two that could actually be a cloud event any anywhere where a function is evoked that's a cloud event and an information between that's sent between one state and the next state could be cloud events so they can be passed through the the workflow yes exactly yeah so basically the thing yeah I'm thinking the event here all the event in the workflow will be cloud events right the format will be it's better to be in cloud event format and the information here in the passing between the states right would also relate to the cloud event correction I think I think the triggering of a function even would potentially be a slight expansion on to the h&p uh transport specification right so maybe something remind me a little bit more detail specifically associated with steps also from what I've seen from these these potential workflows there's also sometimes the need for a response coming from a function that's being invoked and being given an event which we don't have a specification for there so again there we would actually need more of kind of a synchronous style of event delivery as opposed to asynchronous but again I think a lot of it can be brought very quickly back to the cloud events implementation yeah so we definitely need to go into more detail on on the request response you know between the workflow and the function itself so that that can be you know definitely looked at and worked through cloud events formation passing between the states even I related let me put this on cloud events and synchronous cloud and the synchronous asynchronous and the response are synchronous basic functions okay we need to define this okay um let me see your case discussion why he's putting here yeah here your case for you okay um just want to make sure okay good and so let's go back here I think we also derived some requirements like you know we need handle event and then we need the correlation between the events um I can put that in later so I want to go through the next the next use case this one any questions on the previous use case any more questions so let's go through this use case then for hard to do yeah yeah I'd put this in so yeah I can probably I mean so this is basically illustrating if how you can implement the workflow for streaming video on demand so you basically put a massive video file mpeg mp4 whatever and then you basically go through a workflow so it basically runs the output is multiple uh streaming streaming format see the mp4 hls or dash so again going through the workflow once the instance starts if the minute a user uploads a video with metadata it basically triggers either most probably an objective and I would assume it'll go this will this will transition state one to implement function one function one will probably be an ingestion function so the ingestion function was essentially it analyzes the video what what is its resolution 1080p 1080i 720p blah blah it can it can store that information to database it also sends all this all this information the response of the function one it sends it to state two the minute it goes to state two depending upon the analysis that was done as function one it goes ahead and depending upon the metadata file it goes ahead and starts multiple transcoding functions again I would assume that the input will specify what kind of streaming formats you want one either mp4 or mp4 and hls or mp4 and hls or dash blah blah whatever anyway depending on that state two will basically go ahead and start multiple transcoding functions as soon as now these will be asynchronous so that because it'll take a long time so the functions have started you now go you and you basically wait in state three as each and every as let's say at some point in time the mp4 transcoding is done event three will come when event three comes it will basically look at it see if it's complete and basically update the database and then a function three will copy the the file either to an output storage or whatever and then again go to the next state which says whether all events are completed if not it goes waits for event four and five and basically the same thing happens and then finally the workflow ends so at the end of the at the input of the workflow you have submitted one a single massive video file the output is depending upon what kind of streaming formats you want the output is those particular streaming formats nicely arranged on the output storage any questions on any questions okay and below given the description of what I just mentioned so you guys can read it and for your questions feel free to ask yeah yeah I think you know this later you know you can always put in comments so but I think you know so from user point of view you know the user will specify such a workflow and then back end will take this workflow and then to implement to see how to manage all these service functions to instantiate service functions to support this right and also use the workflow to operate on these service functions so no questions how about is there any other oh there's another long I added that but yeah I added that but that is similar to the low network processing discuss story so I think you can skip that one right oh okay so you put okay I see so this is similar to the long yeah also you and oh do a similar thing okay good so so I think you know um so let me put down some um okay hold on yeah it looks very similar except that what I put inside one function he has broken that up into multiple functions but yeah essentially it looks pretty much identical yeah yeah okay oh okay good okay I see so this is um I think I would like to first go out to see any some people could you put your name there okay I think there are some other people joining later if you want to put your name like you know um char char char char char right okay so um I think you know we also derived some um we can see I think we want to summarize here we need to define this and also I think you know I think we agree do we agree that you know we need um a state need a state date to handle the events handle the events we need information passing we need to need a mechanism to specify information passing passing between states right looks like this one um for heart we need the information passed from state one to state two right because the analyzed the video results right something like that right are you are you saying that's what needs to be in the standard or that's just something for the for this particular workflow I think what Brian I think what Brian is saying is we need to standardize the events the way that we pass the events between the states and the the response of the functions I'm not sure if we want to I mean and Brian can basically add whether you also mean passing information between the states is that part of this this work group that we are trying to do yeah that's a great great question I mean that my my perspective is that again we're here to try and define a specification that our systems can adhere to in order to be able to participate in kind of a distributed workflow so I think the in terms of what we could potentially try to uh delivery here would be things along the lines of an api specification for delivery of events to steps some details if necessary for things like state persistence um a specification around the event shape for step to step communication so something like a step event um a specification for for a definition of a workflow and then how that workflow is basically translated into configuration potentially for each step um and then an api rat evocation of functions so event delivery and then how do we handle things like synchronous evocation getting the response back row function etc I think those things specifically would enable us to be able to design a system that is open and capable of being participated in by all parties a spec for definition or pro so um if you want I can copy and paste some of these notes in there uh I didn't quite catch everything you said you just write here okay um I think I hope I catch everyone whatever I think we also need you know a way to correlate multiple events multiple events to the same workflow right because if that work because it involves multiple events um so maybe Brian yeah you can put in more you think we need to specify there okay there you go so that summarizes uh what I had just mentioned again I think I'm not saying that we should do go do all these but I'm saying that these are some areas that we could potentially uh think about in terms of potentially defining that we'd be directly associated with uh this potential workflow engine this this potential workflow work very good um so I think why some are green and some purple some are black it's because it's dependent upon the person that added the the suggestion so I only have suggestive uh capabilities I can't actually do direct everything so I think it's better oh I think probably dog has that because some of the other I I did becomes black and some become it's a green I do not know why it's all maybe it's dark who has that you know is he yeah I think I think that can only accept suggestions okay um okay so I think I know I'll pin him okay good um so now I think we only have like eight minutes let me quickly go through the next um potential existing offers I think this is um talk about how we we can probably support it um let me see whether I can share I think actually in this document um I think I already put in something which uh uh like the workflow that how we define it something um it's not really it's still in draft state but I think you know on one way to do is we can have you know different state multiple state one point event state in the event state we can specify what kind of event or trigger what kind of you know functions probably we can change this you know uh this change this you know to action to function mode to make it more clear and then these are the functions the real functions so function mode is like synchronous asynchronous I think you know many expressions like you know it's a one event or two event trigger it so this is that this state and then there will be uh I think here there are some you know matching this there's a timeout here there's a result say match what value and then you know and some retry mechanism and what's the next state um and then there's another state with operation state which doesn't need any event trigger I think one of the use case this is to address the the other the this use case for example I think I think so in this state there's no event trigger you just do the some function okay or in in this state you do not any event trigger so there are several state states different states to model different um I mean different steps and then there's a switch state which I think is a branching out state depending on your your match what value and then your comparison how you compare it and then you go to the next state I think this I drive the switch state I address you know some use case like this this is switch state right you go to different state or let me see whether there are other yeah here also as long as you branch out in the state diagram like here branch out and then it's like a switch state so you go to different next state um so I think you know this one I will not go into detail but we can take a look at this and then to see whether this makes sense oh I see some comments already um so maybe I think I would like to use on last few minutes to go through the comments before diving into you know different presentation on the on the solution and we can probably postpone that to the next meeting um because I think you know there are other IBM has another has a presentation too but I think uh he cannot I think IBM he cannot make it today so let's do it next time um at what floor are you treating long okay so this is fine I think you just accept it sorry I did here all between states yeah I think that's good now heroes just accept it so this is one um so we were wrong are you are you still there yeah I'm here oh yeah is it okay I give a comment because you say there should be no um I think it this should be out of I think it should be in because we we we already have this use case to show that we need to correlate them together yeah for for that it makes sense okay good so if you can resolve it that would be good so and this one is good I don't think I understand the mix of workflow steps and what is event yeah does this address your comments it addresses my comment I still don't agree we should go boil the ocean but if the group wants to do that that's fine I know your concern is how we go how the implementation implementation can support this right yeah okay yeah I do understand it simplifies things for the end developer and user so I'm fine okay great I think that's so actually I that's the most important thing because I think this the goal of this workflow specification is more on you know how we simplify the user's um um the user's burden um you know specify the workflow it's not it's really not really on how backend should implement it because we cannot define or standard away for the backend implementation um those yeah will be left out for I mean different implementation backend a different plugin to do it right but we can discuss that that's no problem but I think the goal is to for the end for the front end user's um specification I mean how we can provide specification for the front end user to specify the workflow okay um so if you are fine with that that's good so here no okay to the what what is this me Alex so performing the associated processing to the no next state I do not know what's this mean so here is another your comment um is it for instance that they need for this case even state yeah so this one we're wrong yeah I think they all try together right now if you want to have a workflow that's blocking and stopping for states sure like if that's what we want that's fine yeah also the first the the first one the first event the first state yeah no no because that could be something just triggering a workflow right because we don't need to have another state for that but that's fine like let's not get into that more like if you want to have events in the middle of the workflow that's fine yeah because we anyway we need to have that too okay at start state this state takes input as a natural state of the workflow okay so for this one yeah I think we can discuss this you know whether we want to have a start state or the operational state operation state or events they could be used as a start state to pass on the whatever input information on now hero are you there uh yes I'm okay yeah I mean that the start state is used for to start the state machine I think I think we need some way to start the state machine right so um yeah yeah I think um so so this is we can discuss later because I'm thinking okay if the first if the state machine or the workflow is triggered by an event if the event has not come if we have a start state then that means we have to start it how it started since we do not want to waste resources on the you know on starting the workflow before the event arrives yeah so if we have a start state that means you know we started whenever we want but the event has not come yet while wasting although the if you implemented well the workflow consumes little resource almost close to zero resource um but still that's what I'm thinking with yeah I have a I have a state function in my mind so uh yeah I know yeah so we can approach this two ways either we could have an explicit start state or we can have a field within you know within each state that could be marked as a boolean within each state to say this is the start state so it could be done other way and and if we do the second approach then any state an event state an operation state a switch state any one of these states could be marked as the as the start state yeah I think that's a good suggestion because we never know how the each each user each developer's workflow look like right it could start with an event state or could start with a operation state which doesn't have any event or could start with a branching of switch yeah I think that that might be the best approach yeah it could be maybe would you like to add your comments to the hero we can decide this is more we can decide this later when we go into the detail I needed to drop off let's like yeah I think we passed 1130 oh yeah yeah okay okay so I'm going to go through this and then um to accept it okay all give more comments I think that's all thank you very much let's continue discussion in next meeting okay thank you everybody thank you very much thanks bye bye that's fine sorry no it's all good can I see yes can I talk a little bit pardon can we talk a little bit oh sure yeah I think you mentioned I need to make a comment into the disk document but I feel we need to discuss a little bit about the action array action array you mean the action the function right in sequence or in power yes yeah okay yeah sure I think we need yeah in order to explain the parallel of sequences I think the the array might be better to be a two-dimensional array because the multiple slate can have a so that the multiple slate can have a sequence of function so so it will be a the two-dimensional array would be a more appropriate appropriate that's I think okay I think would you like to write this in the in your comment or you can put into the the text the document that will be easier yeah then you know write in the comment and then we discuss through that and then we can discuss in the next meeting you can put a agenda you know you know the meeting minutes right you can post agenda I will post some agenda you I also post what you would like to discuss there okay okay okay so thank you yeah thank you yeah bye bye yeah thank you okay bye bye