 Hi Klaus, can you hear me? Hi this is Falko from Komunda. Hi Falko. Hi Kathy. Hi yeah. Hey Kathy, this is Mauricio. Hi Maurice. I'm sorry, I pronounced your name correctly. Yeah that's fine, that's fine. It's a complicated name that's pronounced in English. So Maurice, Mauricio Salaboy, it's all fine. Okay, okay Maurice, okay thanks. We have Klaus as well from here. Hi Klaus, I think he's muted on his end. Yeah quite right, I muted, I was muted. Sorry for that. Hi Klaus. In the meeting minutes. Shall I, myself? Yeah you can put the, I hope. Let me see what that is, your name. Maurice. Thank you. Yeah you're welcome. Thanks. Yes, Klaus. Are you, is this your first time to join the meeting? I was there also last time, last week. Oh last week? Oh yeah, okay, okay, I see, yeah. Hi Tiumia. Hello. Hi Tiumia. Georgian, sorry I hope I pronounced your name correctly. Yes hi, it's Jorgen. Jorgen, okay, Jorgen. Could you mind typing your company name? I can type it for you. Which company are you with? Sure, I'm at Pivotal VMware. Oh VMware, okay. I have the dog I can type as well. Yeah, okay, I already, okay, yeah, you can correct it. There's a holiday in the U.S. today, maybe that's why some people might not be able to join. Oh yeah, yeah, right, that's right. Okay, I think we can start, let's just say it might be a holiday. So original, I think I put the so first maybe the question time. Any person would like to have any questions? Before we go to the topic discussion? Yeah, maybe last time we talked a lot about group contributions from this work group. So has there been any final decision on that? How many people and if and what topic? That's a good question. I think last time I think we decided just one person and then it's Tihoma, Tihomir. And then the topic to discuss, we haven't really discussed that yet. We can discuss that. I'm not sure Tihomir, I will maybe in the next meeting. I can do it now if you guys want. We can start talking about it and I'd love to get people's opinions early. But just to kind of, oh, go ahead. Just continue please. But you mentioned last time that you have already like a slide deck. Maybe we can share that as well. Like put a link here so we can access that. That might be a good idea. Or maybe like a starting point. Hello? Yeah, I'll do that. But my decks are currently kind of specific a little bit at least I have a footer for other conferences that I've done. So I just have to update it to kind of remove that and remove some of the slides that are not needed for our, you know, our stuff. But yeah, I'll do it and I'll post it on the channel and everybody can look at it. Okay, thanks very much. And you mentioned you also had a demo that you can show. Maybe that's something that we could have a look at during one of these meetings. Yeah, I mean, I was hoping maybe today if you guys feel like it, it's your decision really. So yeah, it's up to you guys. I think it's a good starting point not because I want to speak or I want to do anything is just because I think for even people that are getting involved their last meeting kind of took off with different agendas. And this is a good kind of starting point for new people getting involved to see why or what or who or start raising questions. So if you guys agree, I can do it now. If you guys want it in the next meeting, so I'm fine with that as well. So just let me know what to do. I would love to see it. Yes. I feel that it's also going to bring context for the pull request discussion, right? Yeah, regarding the event state, Cathy, I just wanted to let you know, maybe you've seen already, I've closed the pull request with like five billion comments on there. I've taken all those comments in consideration and I've raised a new pull request, which with even two examples which cover the two examples that you have mentioned in the comments, Cathy. So those should be covered. And really so far I got some comments from Doug. But if you guys want to start looking at the PR and providing more comments, I would like that as well. Okay, sounds good. So I think you know, for these two topics, probably we can take it off because this was originally regarding PR. I think the homeless PR, since he has closed that and then created a new one, so we can probably start to look at the new ones, you know. So what is that? So would you mind to post that new PR here? I think this PR is closed, right? Kihomia, is that right? Yeah, I closed it because after all the comments, there had to be some changes done and it was just easier to do. A new one, but where is Chad? I'm sorry, I'm not good with Zoom at all. So you guys. Okay, so here it is 162. 162. Okay, so you are not. Okay, so I'm going to replace this PR maybe with a new one. So you say you have a new one, right? You don't know how to post that link? You just copy the link. I didn't try to just post it if you can see it in the chat section. Oh, in the chat? Okay, let me see. Oh no, I'm sorry, I didn't zoom. It's okay. Let me find my chat window. Oh, let me see. Where is that chat window? I saw it. Oh, here. Okay. Oh, where is my chat window? I don't know. Okay, I'm not as good at this. Oh, here. Okay, got it now. Okay, so let me post it here. So of course, you know, I don't think we can, I think probably it's good to everyone, you know, go offline and review this PR. So the, so how about the, I think you know, Tihomia, I haven't gone through the PR yet. So this PR, we're going to support and all, right? Post and then, and then. Yes, yes, it, it, it removes the string expression, like what we talked about, but in addition to compliment all the comments, it does support exclusive and, and parallel. So or and and, yes. But not mix, right? But not mix. Only either end events or, or events. Is that right? Yes, you have to the event state has to act. Once you declare, you, you, you do it kind of like a gateway, either it's exclusive. So one of the branches will trigger or it's parallel where in your case, that's the end, which all of the events must be present in order for actions to, to execute. And there is also a difference between a few events state is a starting state, which means it triggers instantiation of the workflow, or if it's an intermediate state, which is, you know, it's, it's, it's a transition from another state. So a workflow instance already exists. So all that is covered, I put examples, I put images. And so it's much more in detail and more understandable, I think that the original one that apparently creates a lot of confusion. So yeah, take a look at it now. And then, then, and whenever you have time and then let, and then put some comments on there, I'll see where we go from there. Okay. I do want to link one more in the chat if you guys don't mind that I think it's important, which is the 160. Because it updates the specification use cases. And I would love to get comments on that as well, because I think the use cases is one of the first things that people look at. And the ones that were there before, they were okay, but they were more like examples rather than specific serverless use cases. So, you know, I updated those. I added four or five new ones. And if you have any more ideas, either put them in comments of the PR or, or feel free to do your own PR with adding more use cases, that'd be great as well. So yeah, if you, if we can maybe discuss the 160 as well, at some point during a meeting, that would be nice as well. Okay. Okay. Um, so, okay, then since we turned that, I think that we need to discuss. Would you like to, like, to do the demo or would you like to discuss this issue? Yeah, I mean, I have no clue how to share my screen on this thing. And I'm logged in twice because my microphone doesn't work on my laptop. So if you can give me permissions, this is like T-Serdilovich. That's my username on the laptop. In your laptop, you will have to share a button, right? Right below the, like, besides the chat button, you have the share button as well. And it says you cannot start screen sharing while the other participant is sharing. Yeah. Probably Catherine needs to... So yeah, I can stop sharing and then, you know, but I just wonder whether, um, would you like to discuss this issue? Will you state, stage, or step? What else? Maybe we can discuss this time. Okay. I'll stop sharing then. Then you can share. Tihoma. Okay. I'll try. Can you guys see my screen? Yes. Yes. Hello. Hello, my screen. Anyway, so what I'm going to do is kind of start off if I was new to this. And I don't want this to be a monologue, please, please guys, stop me at any time. Tell me I'm crazy or whatever and ask questions. I don't want, this is not a speech. But what I've done so far, go ahead, is I have given a couple of presentations on this already and I wanted to show a short demo and I don't want to go through the slide deck as I will share it. But I want to show you a general approach because we have some of like big names usually in these meetings and you guys give presentations as well. And maybe you're planning to do a presentation on this within your own company or for some public events. I don't know. I wanted to share some of the key concepts of this that I have been presenting to new people and kind of get your input on it or give you ideas of what you can present as well if you're talking about this to whoever. I usually just give a small introduction to Serverless. That's kind of all of you guys know. But you will see why pay for value and this is something that I want to show the slide on because the pay for value for workflows in Serverless environment is different than functions. And I want to I kind of emphasize that a lot and you will see why. So we just say, hey, I show this example and I will make this big. The way I show why Serverless workflows is important is by showing a function, a Serverless function. And this is just an example of a C sharp function. And what I say to people is, look, what is the serverless workflow is supposed to work was doing in general is offload the business orchestration and allows you to do in your functions on your code that you deploy and runs in serverless environments to really focus on business logic. But if you look at a lot of these functions, you do everything else, but business logic. And in this case, I'll show quickly that, look, this is a function that gets deployed on Microsoft Azure or whatever. I'm not trying to bash Microsoft here, please don't be there. But it's a good example to show that you have a definition of an event in this case, a timer trigger, you have to configure the cron job, you have to configure your services that you're going to call, you have a control flow logic in the await statement, do we do something in parallel? Do we do a synchronously, a synchronously, then you have again, control for logic in the for each loop that goes through some list of to do items, and, and completes the ones they delete the ones that have been completed. So if you look at the serverless function, you have, you don't actually do any business logic in here. The only thing that does business logic is some other service. So this is kind of where I go into showing that why workflows are even important in this environment, just like they are in others. Then the other slide I wanted to show is the most important thing about using workflows and things that I think is important and you'll see why is this thing in red flow control patterns. As we all know, and we have some big guns in here that have been around workflows for decades for, we have developed many, many workflow patterns for control for logic, for data access, for error handling, you name it, there is hundreds of them, even for a simple fork and join, there is over 40 of them. But why is that important in a serverless environment is because of the cost. If you see AWS, and please stop me and ask any question, if you look at AWS pattern of billing people for workflows, they bill and per transition. And I'm pretty sure that everybody else is going to follow a similar pattern of billing. Having a serverless workflow in place does not mean the cost is going to be reduced because now you have your cost of functions and workflows. But we're control flow patterns and why this workflow stuff is so important for serverless specifically is the cost itself. And you see here an example that introducing a simple control flow pattern like a fork can seriously reduce your cost of this stuff in serverless environments. So in case we can say step two in this case that does nothing can be avoided, this particular transition on the right hand side you see in the red, we don't have to pay for it. So whatever we do going forward as far as pull requests goes as far as changes of what we do, have in mind that this cost pattern, the same thing is really with another thing is scaling. If we go back to here, things like event states that actually trigger work for instantiation, we have to have the ability such as for example this reference in something else rather than using some sort of string pattern is to scale. So our serverless workflow have to be able to scale to zero in wait states and then continue. So a lot of the work that I think I will be doing in the near future and everybody else hopefully can give input and also work on this is really be able to define these wait states and how to scale the workflow to zero, how to continue using correlation token, test tokens, things like that and somebody might have a lot more idea about this than me currently and we can collaborate on that. So please be aware of this cost. Right? As far as who's out there, I put all these images you can tell me to remove you or something but there is a lot of this of this stuff going on right now. Every month there is like I said a new workflow popping up and why are we important in this space is because we provide a standard and like I said before if we don't do it somebody else will. This is not something that it's a what I want to say is it's a pretty hot topic right now because mostly of the cost because I don't think people have figured this one out yet. Sorry that's interrupt but is it on purpose that you don't talk about Amazon in this view graph? You want to talk about the big guns here but Amazon is missing. Oh sorry I didn't see it. Oh sorry sorry okay thanks. No sorry I should maybe put Amazon to make sure sorry the image is probably not clear but that's kind of like the main point and then we say you know basically I'm trying to say you have all these different workflows. They all use JSON, they all use YAML, they all use whatever but at the end they're not proprietary, they're not portable, they're not vendor neutral and you are basically vendor stuck once you pick a solution within you know your company or whatever you're doing and that's kind of the value of serverless work for a group and serverless work for specification. That's it and I kind of go into you know what it is you will see during the demo and I really want to emphasize about human readability. I think that's another big what I've been asking questions during those meetings. A lot of people are long-term BPM and two users and I don't want to get into any wars with that or because I have been around BPM to myself for a very long time so that's irrelevant to me but human readability was a big thing and I just go through different things like the states that we have the branching and stuff like that at the end I show a demo. So this is kind of like the presentation that I have. I'll post it once I remove the footer and some of the stuff regarding the redhead specific that's here kind of like I remove that as well and then you guys can add to it or give comments or whatever but I and that's it for the slides if you have any questions let me know but I did want to show kind of like the demo part. Oh what have I done now let's see. All right so where do we see one second I want to see something real quick. All right so I have this all started. Okay good. All right so let's see this bad boy in action let me just delete my test that I did yesterday but what I have here you don't have to be a developer to understand I have a simple Maven project. He has no Java classes he just says resources which are some JSON files in this case our serverless workflows is the specification defined can be either represented in JSON format or YAML which we added recently either is fine because I think Alibaba uses YAML specifically we have to kind of you know cater to both sides of the markups which is fine. Now this is just an implementation which we have at Redhead I don't want to talk about it I don't want to say anything but you don't have to have any Java classes you don't have to have any setup you just create a project it's running on this thing called Quarkus which you can read about as well but we're just going to create greeting dot SW those JSON is our extension our implementations can use a different extension because we don't want to we have a hot reload feature we don't want a hot reload in every single JSON file because you might not be a serverless workflow so we do SW.JSON and let me see if I can get in presentation mode. All right so you've seen the specification you've seen all this crazy documentation but now let's see what the heck this actually looks like of course we are representing our workflows with JSON so it's a JSON object every workflow has should have an ID and let's call it greet all right we're doing a simple greeting hello somebody workflow a workflow already has a name and of course we have to have a start state okay so this is the starts at property so let's say greet person all right now another thing that we have to do is oh yeah and also we can specify a version it doesn't matter really so you can version your workflows and also if you you know update it and stuff like that the next thing we're going to do is we have these things called functions now these are the serverless functions that we can invoke we have done this in our specification which is a change for example to AWS and I think this is a upgrade that we have reusable definition of functions we have a lot of different states like operation states event states stuff like that they can have actions and actions can call a function in AWS for example or other ones you have to redefine your functions over and over again in each action we have this a little bit ability to define a reusable function all right and let's give it a system out function you can give it a type or the resource knowing my implementation because I my internet is flaky I don't want to actually call a serverless function I'm just gonna I have a assist out type this is just gonna print stuff out so this is a definition of a function now that can be reused throughout the workflow states all right and now of course we have to have our states all right so we have many different states and each state has a name now let's call it the same as what we said the starting point or the start stable workflow is we have different state types as you can see these are the current types that we have all right we can add more if we need to but what I'm using right here is VS code is just an editor and because our specification has a very specific JSON schema definition we can write simple tooling to do stuff like this all right so but basically fills you all the options that our JSON schema defines which is another what I have to say addition to what the AWS state language has they don't have a JSON definition for this we do and I created a small little VS code extension that helps me with this so let's do a simple operation state if you guys remember operation state is just a state that executes actions okay an operation state could have an action mode let's call it sequential and an action state can have actions oops actions all right so now we have our actions another thing before we define our actions we're just going in our serverless workflow we don't have an explicit end state we can just say end and there are different types of ends our type can be an error so our workflow says I our execution is failed the notify other workflows or other services we can send a message in this case we send the cloud event out at the end of our execution of the workflow in this case I have a signal which makes sense for our implementation but it doesn't make sense for the workflow but terminate is a hard end so when we execute all our actions in this state we're just going to terminate the execution of our workflow instance so far so good guys okay yes all right no please stop but but as you see right now this is all human readable so far I'm just explaining it this ago because it might be the first time for some people to see this and next time I won't bother with this anymore but now let's finish this and see you're running and then we'll go from there no let's create an action an action has a reference to our function and this is something we've added as far as reusable functions go so I can say I am going to whoops reference my system out function but of course I can pass it my own parameters all right no parameter is just an object you can have string keys and string values in this case we can have I think this one takes a prefix of hello we're just going to greet somebody and a message parameter and this is something that's kind of confusing I think to some people mentioned this but it is data workflow data when we start our workflow we will give it some jason which is the workflow data that starts this workflow data is then going to be passed as the data input to the starting state in this case our greeting person state at this point it is available to the state and we can reference it okay we don't we can also filter it and that's where the state filters and all the different filters coming that I'm not gonna talk about now but let's say we just want to and we reference it with a dollar sign and we just want to say hello first name and this is really a it at this point our workflow is executable we we can see that it is 28 lines of code if we did gambling would probably be 15 I don't know and then just to show you the execution of that where am I I'm just gonna start quarkus this is the is going to our implementation redhead it looks at the workflow it's going to compile it into some internal API that nobody cares about and make it executable now the cool thing about the implementations the one thing you have to understand is how our workflows instantiated we have things like cli we have things like that but in most cases in the real life environment it's going to be actually instantiated we have probably a some rest API either some service or something what we have we generate a rest API in case of us for things like the workflow instance any event state which is a wait state things like that and in this case we have our greet is this the let me just double check yeah greet so the id is greet so we have generated a rest API arrest endpoint for greet we're just gonna try it out we're just gonna say all right so what I'm doing now is I'm sending Jason to this rest endpoint called greet passing in first name is my name and we should create instance of this workflow and here I am our workflow got executed and I got hello to you okay now one cool thing about serverless workflows that are just usually showing meetings is that we have we don't have to restart our applications and stuff like that so it's very easy to for example add another state so let's add whoops that's not a state let's add another state um all right and then I'll get to the to the good stuff don't worry what what am I done here okay I can't even kind of paste right all right so let's say add another operation state now instead of and here we're gonna have let me just do presentation both instead of and we're going to have a transition on transition is going to have a next state of send off person let's say and we're going to transition to another operation state which has the same function but we here say goodbye and that's it we can send another rest endpoint request to this to start a workflow instance and here we are we are with goodbye so this is the basic kind of hello world example that you can show to people it takes seriously like three minutes to code and actually run depending on your implementation now to some of the better stuff to actually show people here is I have some other examples and because they're a little longer I don't type them up myself but I haven't but as you can see there are only 40 lines long in this case what we have is use of event state and this is why kind of event state is important in this case what we want to do is have a workflow get instantiated on a cloud event coming through a Kafka pipe and also at the end of the workflow you want to produce a cloud event which going to trigger our other workflow so this is kind of like an inter workflow messaging based art orchestration where our workflows can consume events via the starting event state or in an intermediate event state is fine as well but at the same time when our workflow is completed we have the option to produce a cloud event which then other services or other workflows can react to and in this case I just wanted to show you we also have reusable let me do presentation mode we have also just like functions we have reusable events in this case we have two events defined one is the customer arrives event which is a comes from our Kafka stream that is defined and while workflow completes we have a customer departs event which also you know is a Kafka based event we have the same type of function which is our system out but in this case instead of reacting to or getting instantiated we arrest API passing in some JSON our workflow is going to be triggered by an actual cloud event coming through a Kafka stream so this is the same type of state which just says hello and at the end the only thing that's different is our end instead of being type terminate we have a type message and we reference an event that we have defined here which needs to be produced passing it in some information okay now this produced customer departs event is going to be then consumed by our departure workflow which just says goodbye so it's the same type of thing that we just showed within our greeting workflow but instead of rest API and jason we are reacting to messages so let's kind of see how that ends up we have I have my zookeeper running I have my Kafka locally running here I just have to create now I am connecting this is a console producer this allows me to send messages to my Kafka topic and because our workflow here arrival has a topic defined over arrival I'm going to if you can see here there is an arrival topic that I'm going to send my cloud event to now I don't have to send all the stuff from the cloud event or the ID the timestamp what I'm going to do is just send the data um and in this case let's uh salvo okay and this is a actual cloud event format the only thing I'm doing is is sending the data section which is the payload of the event now when I send that event if you can see we said hello salvo that came from our arrival which reacted to the arrival message if you can see now our arrival workflow at the end has sent I'm sorry our customer departs event which you can can see here this is this particular message which then got consumed by our other workflow and which printed out goodbye salvo um so this is this example is more of kind of like to get people's interest in in more than just hello world use cases but also kind of show our event state a little more and that's all I have can I ask you a question who is creating like the cloud event there like because you have like a Kafka consumer line but who is in charge of creating the event when you send the data um cloud event there it is actually uh well this is implementation specific you don't have to but within um the the runtime that we have for this we enforce cloud events hundred percent so you actually like have to send the cloud event format we use the cloud event uh a java api to convert that message into a cloud event uh object and then consume it it's payload yeah that's it yeah so I don't know how to stop sharing anymore you have probably a button on top now on the on the on the top barrier stop share okay so that's all I had I mean I hope you didn't bore you too much but showed the little bit but that's kind of like the thing that that that that we are doing here um that's what we're doing within this specification about the just the double question on my side oh sorry no go ahead what would would be possible to make um the usage of cloud events more more visible in this demo it like a look under the hood yeah I think yeah I mean I can I can try but definitely yeah this right now it's gonna hidden by only just sending into a Kafka topic yes I I'll try I'll try maybe just as an idea I mean it's just a proposal no definitely if you have any ideas I'd love to use thank you ma'am thanks for the demo it's really really nice to see this running um while you were presenting the second the more complex scenario I was thinking about this events uh definition at the beginning of the workflow how would your workflow instance would you also subscribe to the departure topic is that happening underneath sorry I didn't understand your your events definition um has posed the arrival topic in Kafka and the departure topic as a Kafka event type without specifying whether there is an input subscribe to topic or whether there is a publish to topic oh I see no I mean you need to subscribe to both or hard um if if uh if uh well within the events that aren't uh specific our event definitions are global where is just an event definition uh it's reusable being reused in the states okay uh if uh well the events can be they're consumed or produced by the workflow they can the only way a workflow can produce currently in our specification and the cloud event is in the end state is is is is when the workflow finishes execute uh that's the current way if there is other ways that we should be doing it I'm all ears for it uh the only way to consume is um via event states current so there is no no specific thing by saying I am producing or I'm consuming you kind of have to look at where the event is used within the workflow uh states current the this end um semantics of saying emit a message to me seems like a collapsed version of transitioning to a state that would submit a message right so or an event maybe we'd call it a better quality event not message because it's a so I mean is it is it do you just submit any message to a Kafka topic or do you actually uh encapsulate it as a cloud event yes I mean both uh when the event is produced it's first converted into cloud event JSON form so it uses a cloud event SDK Swift binding and so on yeah okay yeah we don't necessarily use the SDK because this JSON format is so simple we created our very simple version of that currently but yeah definitely you should use the SDK so I like that point Manuel because that's yeah some of the languages they usually close the execution with sending an event which it might be internal or external so yeah it's a good point there I see the benefit now with the demo or typing all the workflow definition I see the benefit of collapsing this into a more abstract notion of okay end this date with sending a message so to spare the developer from defining an extra state that is just for the purpose of sending emitting the event but the message on the event it should be the same right or it's it's a little different I mean is there any difference between those two things well this is kind of borrowed from you know business process BPM and two where you have different types of event states I mean end states right you have a end event you have a message and event signal and event things like that and we can borrow this is like the whole point of us what we're doing our benefit towards other workflow like even AWS is because we have a lot of minds here they have been seeing different types of workflows implementation so the more we can borrow from our experience and our good experiences it's good so but it's not it's not possible to emit an event and continue the workflow because it's either terminating currently no we with there is such thing in BPM and two for example intermediate events where you can send messages and consume if you guys would like to add that this is why I'm doing this to give you guys ideas for pull requests and and issues and stuff like that because we can add a lot of yes we can add that if needed yeah I don't really want to press too much on on adding stuff so if when there are people using it actively I think this is well most of the because I'm not a developer that has built an application based on the current workflow specification nor do we have a product on it so I am hesitating to just propose stuff for completeness of functionality purpose or whatever and then just just troubles every I mean about it more like Legos like if I want to be able to emit an event currently I the only way possible is to implement it as part of my functional implementation with the termination with an event yes but I can only terminate with an event I cannot emit an event and then continue the workflow so I was thinking about any way to to implement that you have the event state right and the events that it's not yet the meeting right it's just consuming that kind of thing that that was my point in one of the pull requests about like okay let's consume catch and throw us what events which is sending sending and receiving events from the workflow control I think that might be useful yes and the send receive would also touch on the borders of the workflow extent right so you can we have this longer discussion about consuming events but I think it's the same with creating events would they be carrying the same correlation ID would that be stripped off is that part of the workflow how do you currently manage so well the way we have it defined in the specification is two ways okay one is starting a workflow instance where you don't have a correlation key and that is I think what a lot of the comments were in the JIRA like the 50 common JIRA at that point we have a token that you can or cannot use once a workflow instance is started the idea that is within the implementation that you have a correlation key you might have multiple correlation keys one is for the workflow instance yourself what AWS is doing they also have a specific task correlation key so they can start the workflow instance back up once it's scaled to zero on a specific task or a wait state that the workflow where it's scaled to zero so I don't know we have to define that but currently if you have an event state that's not a starting state you want to consume events they have to include a correlation key so they're associated with that particular instance of the workflow if they don't then they might start a new instance or cannot be correlated to that particular one that you started right so I was late I missed a potential earlier discussion about this do you already talk about correlating multiple events no okay do you want to discuss the current pull request that I think you last updated three days ago or I have just one one notice I noticed the end and or and still I wanted to ask Casey actually and if you we can do it through Github issues but my question is when we do get two events like we need to end and or we need to get that Boolean expression right the first event has happened who keeps the state about that event having happened already would you think that this is kept somewhere outside or is this something that the workflow execution system would somehow need to keep that state that the previous one has already happened and that I do not see when I can actually get rid of that state so okay so here's my thought so if there are on the workflow requires two events right you say these two events at end right so the first event comes it's a workflow engine okay or the whatever you call it the back end workflow back end implementation that needs to keep track of you know which events has been received for example event a has been received we keep track of it and then it waits for the next event and then of course we have a timeout right for the two events as a whole right so if within that timeout period the second event has not been received and then you know there should be a specification say it when that times out was what action we should do or what which transition we should go I think currently the span is transition to the end state but we can extend it say if you know these events are not received we can transition to another state we can extend it provide more options a current spec I just say okay if that event is not I mean if not all events are received which transition to the end state okay so that is when I when I transition out of the event state which would be because of a timeout or because it has been completed then I can actually get rid of the state because it's no longer needed okay and then the other yeah okay yeah maybe let's take these discussions to the issues and pull requests that's okay but yeah actually original description the spec has description on that we can probably add that back yeah I know now that description is removed so people are confused about what happened if that timeout received because I did that yeah yeah really take a look at the pull request because it should cover everything now that we discussed in those comments I hope if anything is missed you guys will let me know okay so many I think you know you raised a good point about the you mentioned the the event produced the event produced on the end state right so I didn't quite get your what's what your point so what you would like to see what's your what's your thought on this currently the workflow cannot emit an event and then continue okay so you like the workflow to emit an event and then can continue to another state right yes okay so that means you know this event producer this event emit that happened on any intermediate state right at any intermediate state right yes okay I see yeah I think you know we can think about that yeah but do we need a new state or do we need like an internal kind like operation of the existing states to do that I mean my my original thought was like okay that's a different state that it's going to emit the event in the same way that we have like we see them but I think you know okay yeah so so we can discuss about that I think the first thing if we want every state if we can we we would like every state to be able to emit an event I think the first thing we we should do is to change the end flag or end state I think the homie you mentioned that you are going to change it right change it back right to the end state is that what you have you done that or no we had originally we had an explicit end state which we changed to the end definition that each state can declare itself to be an end state and with this this is still okay there is probably no need for that what I think what's being asked is is to create possibly a new state called the like an event producer state or whatever we end up calling it which is an intermediate state that can produce the event if cloud event if needed that's a good point I think if we should probably add one just to have one but yeah I don't know yeah yeah I think you know we can either have an explicit event produce state or we can add that producer into any allow that producer to be specified in any of the existing state or yeah there's many ways you're right either somehow every state should be able to produce an event but I don't think states like what we have some states should not probably do it like parallel states should probably not do it choice stage should probably not do it pass through state should not do it I mean there are some states that really I mean maybe we'll make it part of the actions such as just like a function execution could be a specific action that produces an event so states they can execute actions can also do that maybe that's a good idea or just have a dedicated state for it I don't know yet think about it yeah yeah I don't know yet what's best yeah we can discuss about that you know no matter whether we have a dedicated state or we even have a dedicated state right like you said some states will not be we should not allow it to produce an event then those states cannot transition to that dedicated event producer state so I think that part of the logic no matter how we define still there um so so yeah I think that that's we need to discuss you know which state should not have uh it should not be involve an event producer so that's one thing another thing is how we should define whether we define inside that state in the action or we have a dedicated producer state um and another thing I'm thinking about whether we should have that end state because I'm just feeling maybe in the future we're going to add more information we need to extend that and to have more functionalities so I think an explicit state is clear like you know in our example I see that you show right you have to change this and five so if you have an end state there you do not need to change that you just add a new state that end state does not need to be changed otherwise um it's just my thought you know yeah I've I've tested so far my testing has shown that adding explicit end states adds on the bigger workhorse can add probably hundreds of lines of json code in addition the extension to ending uh I think what we should think about and this is just my thought is is just like transitions ending a workflow can add more rules such as authentication rules such as user like not anybody can end the workflow not so there's a lot of more stuff that we can you add even through transitions for example cannot transition from state a to b unless I'm a specific user type or I have a specific role or a group that's one thing that our specification as far as authentication goes does not cover it all currently there's a lot of stuff we can improve on but right now unless there is a specific need I keep it like this until we find out hey we really need to add it back or something like that but I mean yeah so yeah right now as far as end states being a generic end state before where it could be reused yes we can have one and all of our states contribute this decision to it but as soon as we start introducing states some can produce messages in some case we want to produce an error in some case we want to do this then having the way we have them right now it's probably a little better but again it's not set in stone we can always update if needed was that a reasonable request that came through this change of the event the end state yeah sorry this change from end state to having the end kind of as an event anywhere was that a reasonable request I didn't see that flying by yeah it was maybe the last month okay okay so what's your point so Falco you you're like and still you're like and parameter I mean parameter or definition something like that I think I'm tempted more towards an end stage I find it difficult if certain behaviors are allowed somewhere and somewhere not so how is similar to how we discussed intermediate events would it make sense for example for a parallel state to be in to define an end or a choice to define an end yeah okay so you prefer and okay I think we are running out of time today so it's already just one more minute so I think I just want to remind you know people who drive later you know please add your name to the to the meeting meeting minutes um yeah uh then the next we meet will be in March so if you have any topic you would like to discuss just post it in that meeting minutes in the agenda sounds good oh that's great cool okay thank you I think thanks everyone thanks a lot thanks again for the demo yes it was very very nice yeah thank you bye bye bye