Hey, Tommy. Hey Hey, Remy. How's it going? Pretty good We technically I think only have an hour because I'm pretty sure that the workflow group uses it the exact same zoom call at that At 1 p.m. Eastern, so I have a hard stop at 10 PSD anyway, so yeah, I gotta eat lunch. So yeah, it's all important stuff sure So let's see who's gonna join Did you have a chance to see the video? No, unfortunately, I did not I apologize I just saw this morning and I haven't had chance to actually run it so How long is the video by the way three minutes? Well, I can I can do it like yeah, maybe yeah That's that's that people join first and then we'll do that just out of curiosity. Did you um Did you implement a pink service like I described here? Yeah, it's just I need to check the the pink is not exactly the same I I have a pink service and a cat service, which I can call the way I want so I call it Garfield And then basically every 15 seconds again the cats and an event of like an action like a sleeping sitting Yarning whatever and I also did the gateway so but I can Why we wait I can show you what they did and I can restart Someone joins Yeah, go ahead and go in and start you can always redo it again. It's only three minutes. Let me stop sharing There we go Okay, and it's like those Macs with like a broken keyboard. It's super Okay, you see my screen so Basically, I have free services the gateway Garfield and Pink service so they all are on you see the URL So I just connect them on several ports In the discovery you basically see the slash service is just a display of slash services So Garfield is like as soon as it's and all those type events Correct me whenever I say wrong things about like the Word I think I need to read the spec to get every words perfect Then the pink service is basically with this source and he's sending this event From this UI, I can basically subscribe when I subscribe here So the pink is every five seconds. So you can see that I start receiving the The pink events cool. I Can also subscribe to Garfield and in that case We'll start receiving so pink is every five seconds while Garfield is every 15 so In the next five seconds, we should see a Garfield here Excellent So that's nice, but for me is just like one part Now I have a gateway Which is intermediary Right now he has nothing like in the discovery you can see it's empty but I want the gateway to start proxy and Like being the intermediate of Garfield, so I'm gonna ask it to connect to Garfield So now you can see that in the discovery. I have this So if I subscribe to the gateway So now like the little green thing is just to show that I was subscribing to this So I should see the events arriving here within the 15 seconds. So you see here one event Of course, if as a consumer I subscribe to both Then in the next 15 seconds, we will see a double event because I will receive it from the gateway and also from the Garfield service So here that's why you will see a double one. So just just be clear You said you subscribe to the gateway. What you really mean is you're subscribing to the gateway's version of the Garfield service, right? Yeah, like yeah, so basically it's like I'm calling this So I did some simplification because it's still quite a bit of work to implement all that and do the UI but Like I didn't send the subscription config So like and I raised some questions by doing like by doing that even on the SDK side the way we emit The event so I did publish everything on github and my goal is also like to open the discussion to understand So like in that gateway I can also connect to ping and then suddenly so you see the gateway who will expose basically those two sources and send events from both and Like it allows me My scenario is basically Garfield or ping will be github and like other for provider my gateway will be like a new gateway And so my employee will go to the gateway like my teams And they don't care, but how the gateway connects to Just say when you subscribe to the gateways version of Garfield is the URL pointing to Garfield or is a From the client's perspective is the URL pointing to the gateway or is it pointing to the real Garfield to the gateway directly? because like I want to be able to have network isolation between so and like This gateway should like there is way more feature that I should I was just staying at like a simple first level But so when you connect it automatically subscribe to the service for now without filter So it's already start to proxy even if no one has subscribed to the service yet So like I don't do a cleaver matching to understand if I need to subscribe in advance or not But like and you see as soon as I disconnect it will remove from the discovery sounds and Then now I disconnect the two of them So the gateways not doing anything anymore and then I can still see my two services So in your in your case the the connect disconnect is making it so the gateway is just aware of the service Yeah, exactly available. Okay. Yeah. So this part is basically an API That is not in the spec It's like a proxies what I call that is the API I see for the cloud events gateway Just to say okay Like go and discover this service for me and just start proxying it and same thing for every so whenever you click connect That's where normally if I had a schema and subscribe the subscription configuration I will pop like a form that for you to feel what you have to feel and to subscribe but um, yeah, I just want you know, that's Seem and simplification of the old case, but it was to have something Concrete to work on. No, this is cool. I like it a lot. So so let me ask you some questions as you're coding this up Since your UI thingy here can subscribe to all three things Yeah Did you have to put in any specialized code depending on what you subscribe to or is the subscribe 100% Generic and you only use metadata from the discovery endpoint so it's Only use for now I just put the URL and I consider that the slash subscription because the subscription API like there is a few things that Are weird in my opinion is we put for now the API of the subscription is about Posting on a slash subscription endpoints But yet on every service we put the URL of the subscription URL. So in fact, it's the same for every service when you're in the discovery panel So that's like small stuff Can you repeat that one more time? Yeah, sorry Like I can probably show a bit of the code before it might explain what I do So the UI basically talks to this Service where it's like just a demo to get like all the events because as inside the UI I cannot expose a port to get the events So this is a small service for the UI to be able to subscribe and subscribe and and do that and for the rest When you subscribe inside so this button That is here Click subscribe I will basically end up here sending a subscribe with the URL I want to subscribe and it will go to This do a post on that subscription URL slash subscription We've like the thing to be able to retrieve all the events and then it will keep it inside the service So I store it in like the events buffer and the UI is basically for not just pulling because like I didn't have the Time to do a full Web sockets But it's pulling from this endpoint to get the latest events every time So that's but that's using the endpoint like subscription here. You can see so that's the speaker definition of the subscription But okay, well, I want to make sure I understand though because every Every service in the discovery endpoint should have a unique URL that you're sending the subscribe to yeah, the URL is coming from the body. So basically If you look here So when I unsubscribe when I subscribe I give him the URL of the service Yeah, so I say, okay, I want to subscribe to this service URL. So we will go to that Do slash discover right now on that one. I do agree. It's a shortcut because it should do the slash discover It's like slash service to get the subscription URL, but basically as If you look every time the subscription URL for me is the URL slash subscriptions Okay, so you okay, so you so you cheat because you know, you're talking to yourself Yeah, I'm not one. Yeah, like if I was not then I will do the like in fact I would use here. I because I have also that data. So I'm sorry to When I click So if I click here when I'm sending is in fact, you can see the response I have the full You have the full stuff with the subscription URL So I could I could use that. So it's just I do agree. I cheated a bit because I Finished yesterday at 1 a.m. So No, because my question was because the reason I asked that question was because I wanted to make sure that sure your Implantation may choose to cheat because you know, you're talking to yourself and whatever But I wanted to make sure that there wasn't something missing in the specification So that you could have done it through discovery as opposed to shortcut and sheets. Yeah, but like my shortcut is really a Quick sheet is like I could almost fix it in a few sec because Right now I'm taking the URL of the service that I display here Why basically the only thing I have to do is to take the URL that is shown is this but yeah, so it's really Quick, but what I was saying is more Like I think when I am going to subscribe to this one if I subs connect those two So now I have like the gateway with like the two to type and Here you will see that the subscription URL will end up being Yes, no, I didn't have a right because it should be That's where basically I should override the subscription URL to say that now it's a gateway It's not the original service, right? Basically what I do because my shortcut is enabling that by just By because when I click on that it's gonna call the right sure So that's just I need to have a right this part But it was not really in part of the spec because it's more part of the service that I call a gateway Which is basically But what I really noticed also is the current SDK Doesn't match doesn't fit well with description and discovery because the way you send the events once you emit the event you need to already know what is your current subscription to send to the current subscriptions and The way the SDK was designed. I don't think it is a great match for that So I need to talk with the SDK people if we think that this case is the right case if I understood the thing correctly And what I wanted to show you is So I'm trying to understand that Because Scott's on the call when you say the SDK, do you mean specifically the JavaScript or TypeScript SDK? Or do you mean all SDKs probably have the same problem? I cannot talk for the other SDK what happened is I Had to do when I emit so I all like the dummy service are here So basically I have my ping service He's just creating so that's just a register of the way I was showing you it allows you to create easy discovery service But then I just create this new cloud event But I had to create a cloud event emitter because in fact the way the SDK was I was not able to plug to the Emission of the events so in fact then this thing we'll call and that's why I created a I created a emitter where basically I say okay emit me this cloud event and Then he will emit as an event. So then my subscription service can Subscribe to this type of events to redistribute it to all its subscription because if you don't do that then you only consider it's a static emission you only emit to one endpoint so I Hope I'm clear. Maybe I'm not but Scott does that make sense to you and do you think the Goal line SDK would have a similar issue Goal line doesn't have that issue. Okay Because basically whenever like when you when you receive a like that But the thing I had to cut inside the subscription service is you have to go through all your subscriptions if they match the filtering to push the event to them and So you end up doing several requests when you emit depending on how many subscription you have in your service Sorry, maybe I missed what the problem is so Did you see the demo by the way Scott I came in about 10 minutes late I Forgot about speeding because Dougie Doug did not put it on the calendar All right So it's in the note though. So I did I did at least do something just not enough So basically the UI What was the issue with the SDK? the way it emits the The the events were not pluggable it seems to me So you cannot implement a subscription API nicely because You have no way to To connect to it to redistribute to all your subscriptions I see so in in go in the go SDK you can set up this the client and stuff But you can change what the target is if that's a question Yeah, but the subscription API create multiple targets Because you have multiple subscriptions Sure. Yeah, that's fine Yeah, one of the time Yes But it was just like so I need to find because I don't think the example Good enough Yeah, I can come back to that I suppose if I try to go too much in the deep there and I will lose everyone but If you haven't seen Scott I can we show quickly is this I did see this yeah, okay So the nice thing is like this You I could be plug almost everywhere So I just need to add like something to add new services And then you can define your own service and you can play around to see the events and and the discovery The one thing in the in the subscription spec I didn't like and I didn't implement was I think in the spec it says you have to use a Query parameter to get the subscription ID So yeah, thanks that I my PRM changes that last night. I did not like that at all Yeah, it's it's I didn't implement that because I was like this is garbage. I'm not doing yeah for me I implemented to be honest this way I Proposed also like a refactor just to say it should be this way we've like you create a new subscription You get the list of subscription you get once so I didn't plan on this way because It was not making sense to To use the old endpoint because like you were you were the one specifying the ID or stuff like that where I Don't think it should be So I this is basically what I wanted to okay So maybe we should learn to that when there is no tree with the discovery Like the other thing was In the open API in the schema. There's also something about proxy Where basically it should not be like it's not me as a client who should define the proxy the server will use So I don't think it should be inside like If you look in the HTTP settings Yeah, there was like proxy credentials and proxy URL Where I should not be able to define those Sorry, I didn't want to hijack the whole meeting So, okay, let me do this since we only have 40 minutes left before we get kicked out I want to see my quick demo. Oh, yeah, sure. Go for it. Okay, so I showed you the The ring buffer last time Mm-hmm, but we'll set that up again. And if you don't remember it's so service one Downstreams to service to so basically like This is the resulting catalog of this service and it's pulling from this middle service And then the middle service is gonna pull from the rightmost service. So Note see service outdated is here outdated and before before we had epoch that outdated service would would propagate the ring as a little bubble of Incorrect data, but now we have epoch and we can see that The outdated service that the middle server hosts out of its normal catalog has been replaced by the actual authority of that service So cool now it's steady neat So there's just kind of proving that the epoch thing works So when you say the I want to make sure on the same page Let me say epoch thing works. Is it because you assume that if you change any metadata about the service you now own the service well My assumption is that you don't change the metadata or the epoch If you're Okay, so and then I was like what wouldn't it be cool if this Discovery service could actually, you know host itself And so if you notice it has a Z Or sorry X Y and Z But also this discovery service from net met cloud met a cloud meta is just the stupid name that I invented for this thing So I can curl the little closed And on port 80 and then look at services pipe this through the GPU and we see that We can look at this so This is the particular service and it is the subscription endpoint for this discovery service it directly So we can leverage that Over here, I'm gonna I'm gonna run a little Back for a sec. Let's see the output there. So it's interesting that So that query the discovery endpoint Entry but your your list of events is interesting Is that the is that the list of events that regenerate or is that the list of events you can get These are the lists of events that I can get I can subscribe to these I invented these right Okay, I'm sorry. I just yeah, that's correct. It's just the way the way the text was written there I thought it was the list of events as they were being generated. So there was a live stream. Okay, never mind I was the description through me. Got it Never mind. I was just researching it.  It has no content type no data It's just the I subscribed and now I can do the the same demo over here where middle service propagates the C and D Services and they show up That's neat And then I can run the final service in the ring and I should see changes over here on sockeye Once it propagates it propagates every 10 seconds for this particular demo and so sockeye Collates on subject and the subject happens to be the service that it's talking about because this particular event stream is about Service entries in the discovery catalog. So you can see when C was added and it was the outdated description And now it's it's been updated and the description is the correct and we also got We added D and a and B All right, so That's basically my demo I can oh right. Oh, sorry. Okay wait one one one change. So we'll shut this down. There's no storage on my This thing We will add the filtering. So I only want to see updated events move too much and then we'll register here and Then we'll go and run So we should get no events until I start up this service and stuff starts get getting propagated So we'll just wait a second for that Cool. So we only got one event because the filtering works and we get that one updated event from the internal discovery. So Why I'm showing you this is we can get both push and pull for catalog changes based on this because you can Pull the endpoint for you can register. You can subscribe to it and get changes Kind of cool. Very cool Excellent Okay, so me Okay, so let's let's go back to here then so you both you guys showed really cool demos But I'm trying to figure out is What pieces of those demos do we need to actually write down in this document for other people to implement? Or what do we need to do in order to get people to start? Sort of playing in part of this game, right? So for example if if I Forget a minimum people will need to expose or register or let us know what their discovery endpoint is which is why I was assuming Everybody needs to add their own section down here but do we need to Formalize what people do with those endpoints in terms of what queries we expect them to do or should we leave it Freeform so for example you guys both did something completely different with your discovery endpoints, right? Scott you got the circular thing you do subscribe to it Remy you did a gateway thing going up to it and maybe maybe we should leave it completely freeform So people can do completely different things and try to push the system But what do you guys think is the bare minimum? So anyone wants to play in this game should be forced to implement. Is it just a discovery endpoint? Is it scary? Yeah, discovery and subscription because I think without it it's It's hard to demo something that is nice So when you okay, so obviously they need discovery and point list of services in there But you then you said subscription you mean subscription for each of those services, right? Well, I think the discovery endpoint maybe one of the qualifications is that the discovery endpoint hosts Services that you can actually subscribe to Yes, subscription you're right, but then that means you need to have a subscription API the only issue there is like But it seems that we are on the same page with Scott is we need to upgrade the subscription API because the current version is Honestly, not good to implement. So we Huge plus one. Yep. So I'm sorry. I was taking notes say that again Like we need to validate the new change in the subscription API because we don't want people to Implement the current version of the subscription API like oh, you mean the query primer thing, right? Yeah, like yeah like the whole API was not correct like it was not resource-based for the endpoints and Yep, so honestly good. I ignored it Everybody came to the same conclusion. That's great So hold on a minute. Let's at least let's try to enrol the same way all together By following a new one Okay, just just a quick feedback. I mean I Because even as I'm working on my demo, I was not able to finish it the whole time I Kind of don't agree that having discovery endpoint should be a minimum creditor because I start I was assuming the fact that there's already a discovery endpoint, which is enlisting the subscription URL So I started working on the second half. So does it really make sense to have that as a mandate? So we say second half elaborate what you mean by the second The implementation of subscription manager and basically assuming that that URL is already available in the discovery endpoint So you still need to connect the event producer with the consumer And that is the logic of subscription managers. I wanted to implement just the subscription API and Basically have a messaging back and connect to it So if you wanted to do just the subscription API, which I think I agree with you. I think that's valid Then you would be responsible for figuring out how to register yourself with some discovery endpoint, correct? Yeah, I mean, I'm still assuming that there is a discovery service behind it. It says I'm not implementing it as part of the demo But the thing For me it's like because the next mine is still on the locars, but I saw that scott is using Like already a public endpoint so we could all Make them publish and then To subscribe we will need to have the discovery that works so Depending for me if you cut it or not, it's fine. It's just it needs to be there the endpoints for us to be able to connect And one thing that why I was implementing The discovery service is in fact relying on the subscription service Because the subscription service is the one defining the subscription URL and the subscription config And that's where I started to have some interdependency between all the spec In my implementation and I think it's normal But I was not sure it was part of the intent originally Yeah, I think it does make sense. So because you'd really need to have the url that needs to be published as a part of your discovery Yeah response, right? So it does make sense to have the subscription manager or the implementation of the subscription API first before we start having a response from the For the discovery endpoint So I'm sorry nisha I'm not following you If you don't if you only have the subscription manager api You have to have them Accessible someplace or you have to have it. How are we going to find you if you don't have discovery endpoint? No, no, I'm not this I'm not saying that we should not have it I'm saying it should be as part two. So first you need to have The url to which you can subscribe to and then basically Then you would create a metadata, right? So implementation comes before metadata or the metadata comes before implementation. It's just Okay, so you're positioning it Okay, um Have any I don't I was able to implement the discovery and the subscription apis with no dependencies on either But how do you feel the subscription url in subscription? I mean, that's probably because you already had the insight about what you are and you want to subscribe to, right? I mean, but in a case where we don't have the information that what you are to subscribe to in that case the subscription maybe implementation should go first, right? well, I think It seems to me this is just a choice and how you use the implement it But it seems to me if you want to participate in the demo If you if you're only going to do the subscription api then you need to work with somebody to get your Service registered with their discovery endpoint or if you want both you have to implement both. Yeah, correct Right. So the order doesn't really matter. I mean Just your choice. Yeah, yeah makes sense. Okay Okay, so If that's the minimum people need to do just to participate Do we need to talk at all about? Uh, what do we do to actually test this out? To make sure for example people can talk to the discovery service To do a subscription or should we just say now everybody sort of write their own client tester thingy? And we want variations there to push the boundaries What I was thinking is maybe I can also put the UI Like even as a separate project because the UI is not specific to typescript. So If we want to iterate on that to add more stuff like I liked the more detailed version of scott is just Doing the UI takes a few hours at least So maybe if we just have a common Because it's agnostic to the technology. So the UI should be almost Separate stuff that we can always rely on no Yeah, if you if you want to make your UI available for other people to To use I think what the way that's missing is the ability for someone to then register their service with you through through the UI Yeah, yeah But yeah, I can talk Cloud events viewer I we use it for Knative mostly. Okay, that's right. Like I didn't know the project Yeah, what I nothing to do with these it's it just presents cloud events in a UI Because what I like with the one I did is like you really see the discovery like you have the discovery plus the subscription So I wanted to display that at first I wanted to have a small maps of the service but It was getting too late to do the graph So scott the ability to subscribe to the discovery endpoint itself to get changes um Do you want to make your The metadata about the discovery service itself available so people can Basically copy that and steal it if they want to spit out events for the discovery endpoint that way we have some consistency But yeah, it's it's all in I'll paste the repo. Okay. Cool. Thank you. Okay Oh Thank you. Well, then oh wait, that's not the really about your sake. I think there we go. Thank you Okay, so let's do this scott I need to work on getting some like the Fake other supporting services up and running. I do have a version of this That's running in the kubernetes cluster that you can subscribe updates for it, but You don't get updates if you don't have a ring, right? If I like on my side, I was proxying directly Without cash, so I didn't really had an issue with the epoch because in fact, whenever you query it Which varies all the service which wouldn't be since enabled in a full production environment. So I need to To implement more like the cashing and stuff like that. Okay. Um Just a quick question to scott scott where where are the events finally resting? Is it So is there a messaging system behind the implementation of this poc? No, no, no, it's all it's all just Fired forget Okay, this is what I wanted to reduce the number of dependencies on this My implementation the config does ship it out to a k native service. My thinking is that I'm going to set the the scale to min one and then You know Maybe make it live for like 15 minutes or something and then when no one's touching the demo it it goes away and resets Okay Um What else do we need to talk about then here? I mean I assume the biggest hurdle for at least Well, actually not enough a hurdle with scott or emmy seems like you guys need to make yourself available on the internet So people can talk to it Yeah I'm not but I um So if we wanted to Register some so scott let's say I wanted to take your services and register them into my discovery endpoint Is that's something that Is possible and we should do that way I can add more stuff and test out to make sure your subscription manager can Can be hooked up to my discovery endpoint that I can then subscribe to it without even go through your discovery endpoint Yeah, I might have to add like a some sort of helper page to help You register your your service into my discovery service if you want to be aggregated into it And that might be interesting On my side, I mean with the UI I've shown you if I make it available online And I just add you the plus then you can do plus and then you create you put the URL of your Service and then automatically will be available on the UI And you can also click on the gateway and ask it to connect and So it's really just adding a button on my side and I can put it if I put it online that we can all play around with it it's just There is no authentication and we will all share the same UI Because under the hood it's the same service unless I manage sessions on it I would need to influence some sort of API that your UI could call Yeah, that's already what I did. No, right But like on my UI basically what I will say is if I send let me if your service stays at Like scott.com Then I will put scott.com into the UI it will ask my API to do a discovery of scott.com slash services From that you will get your all your services and when you click subscribe, you will use a subscription URL To subscribe to it and then it will display automatically Yeah, but you're not going to get my update events Because you're you're being the aggregator for me and I what I want to show is You can register random registry services But I will get the why do you say I won't get Because as a foreigner, it's just a proxy. So every time I ask to the gateway, it will ask you and you will just proxy the call Right, but so I need these downstream services or upstream services to be able to register into the My discovery because it itself is an aggregate Okay, well, like I can put the two other service like the pink service and so we can all display our pink services and All right for me it was a cat that I can continue with this one and The thing is those services like a small discovery and end point They already have everything for me. They are ready to go those ones. They manage subscriptions and And discovery So you can connect to them. So you could on your side add them to your discovery On your service once mine are online. You can probably try to reach to them and add them to to yours Oh, yeah, I see yes I I need to implement that piece because it's It's dynamic, but only through a pink Because and then what I was thinking is just to put the UI to be accessible for everyone So this way you don't have to rebuild it. You can just use it because the UI is just If I ratio basically it proxies a discovery proxy also, so it allows you to in one UI It's kind of a client for the discovery And the subscription but revenue you You just do a simple get to the discovery endpoint to grab lists of services and it to aggregate, right? Yeah, when I aggregate it's If I so the aggregation So what I call the gateway will do the get on all the different services that he knows to get all the the source and display the He will call the slash service on each proxy And then aggregate them into one view, right? And you you periodically do a regate to get the updated list, right? For now what I do like I didn't cash it and it's basically if the client. So the web browser is asking to discover Then he will redo the he will launch 10 requests in the background and and serve with one So I don't there is no cash. So there is no Interest of it's always up to date because I'm always asking to the final service what his discovery is Okay, cool. Okay. All right. Um I think that's probably enough for today. I think once we get our various discovery influence up there people can actually start hitting them playing with them um, I'm sure we'll need to get back together and Complain about each other's implementation choices For me, it's really more the subscription API where I was My my two biggest I would say issue is the subscription API. We need to validate the new versions that we probably both implement a like But to make sure that we have exactly the same now and the second is SDK the javascript SDK because I think I should push back some of the modification I did inside the SDK But I would like to have more an architectural discussion with the sdk people on that because I don't want to change code without them Agreeing with the philosophy Okay Do we last question? Sorry. Go ahead. Do we have the receiver implementation in the SDK already for discovery and subscription API? No, I had to build it. Yeah, same and I that's why I'd like to push it But I had a PR on the SDK the javascript SDK for the discovery service but it's and in fact while doing the full implementation like with Dependency with subscription API. I think there's something to discuss there Yeah, I mean because I was wondering that once we are done with the poc That's where we start creating tasks in the SDK where we create the receiver implementations for all the relevant SDKs, right? Wait, wait, can I sorry you guys are you lost me when you say receiver? What do you mean by receiver? So, I mean, basically you would have something by the end of the project We would have something like let's say a subscription API listener receiver or subscription API receiver So you don't have to implement your own Own receiver for the subscription API. It shouldn't have been offered by the SDK out of the box Okay, wait, I apologize. I'm being really dense But when when you say a receiver for the subscription API Do you mean an implementation of the subscription manager or do you mean a sync to get events? I know basically So it's it's a registration endpoint where you simply start a server and then the user of the SDK registers Their functions like what if you receive a get request? What if you receive a get request also subscription or a create subscription request and stuff like that, right? and in that way, so basically we wanted to abstract some of these HTTP protocol specific Boiler plate into the SDK. That's what I'm assuming that we would head on down the line Okay, so you're talking about a subscription manager SDK kind of a thing. Yeah. Yeah, okay Yeah, like something what we have a cloud event receiver as of today We would have something similar for the subscription API as well as for the discovery Endpoint so in that way that we try to isolate as much boilerplate as possible into the SDK itself Okay, got it cool. Yeah another thing I did implement was just like a simple security check on my side Like when I subscribe I already had like a header with like a secret and when I received the event I verified that that secret is Is the one I sent before like when I subscribe because Yeah, I know that we try to keep the security a side the spec But maybe it's because I work in security field But I think but I think that'd be an interesting use case for that stuff that we talked a little bit about on the phone Called last Thursday, right? Which is in the subscription API spec It talks about certain headers that you can ask to be sent or echoed back to you on Yeah, that's exactly what I use. Yeah, so I use that. It's not to be a good test. Yeah Okay Okay, is there anything else you guys think we need to talk about? Because it sounds like you would seem to go out and finish up their implementations add their metadata for like a better phrase to this web page or to this google doc And then I think this week's call is a discovery call after the usual one so we can continue the discussions there Um, obviously if we have any issues we want to bring up we can use the slack channel Yeah Uh, anything else you guys want to talk about? right now No, I think it's good. If someone can review the p.r. I have on the On the subscription API Would be great Okay All right, you can drop the p.r in the channel. That's the clatter in channel. We can have a look As your implementation going Doug I have um I have a lot of the same thing you guys do obviously Um I have a little test client allows me to do subscribes and stuff. I need the biggest thing for me I think is just to make it available on the internet, which I have not done yet Oh I need to add the filtering support, but most of the other stuff I think is there I just it's just not in a demo demo mobile form Oh, I didn't realize you have to make it available with the internet Well, something has to be available right for us to be able to talk to you one way or another What was the change around The filters array And then the inner filter Oh, okay. Yeah here. Let me see what you guys think because I Yes, that's why I didn't rush the filtering part because it was like I think it's moving Yeah, so here so Because I wonder if I just ignored what's what's in the spec, but I don't I don't think I did Okay, so to me I think the discovery endpoint Filters array should look like this Where it's an array of filters where each filter expression you explain specify a dialect and then the type And then the property you want to assert or compare and the value you want to compare This this is much much harder to implement in a language like go Is it because these properties are dynamic? Yeah How else could we do it to make it easier and go? The way it was The way it was Um, hold on. Let's go back to the way it was So the way it was was this Um, I think this example was wrong. It's supposed to be filter at the top just With a no s right And then inside that is an object that says dialect and then filters Yeah, but the filters was still dynamic based upon the dialect Yeah, that's that's okay. I can understand how to marshal an object internally into it If I can marshal the whole thing at once And based on dialect Oh, are you saying yeah, okay, let me back up You're I think suggesting that I made life harder by moving dialect inside of it Yeah, because in the class he's not But see the problem that I had with it is That what that means is I can't do multiple I can't do multiple dialects in one subscription Yeah, don't do that Well, why Why do you want to do that? Because I because because if if as a subscriber I support multiple dialects Why should I not allow somebody to use them all at the same time? Yeah, I do agree with you I'm sorry for go I'm sorry for go That's the entire reason I moved it in there scott was because it made no sense to me Just say if I support five of them, but you can only use one at a time. That seems silly The only thing is uh, just uh, if we do the json schema basically a filter Is defined by a dialect and all the property Depend of the dialect correct like because if I create my own dialect, let's say French Like maybe it's not gonna be type property and value, but something completely different correct That was my assumption as well. Yes. Yeah, okay. Yeah. So, yeah, I mean, I'm aligned with you Yeah Also last month last week there was someone saying and I I find it interesting that it's really hard to filter on the to limit on the number of filters While filtering can be compute intensive And it was easier for him to put a limit on the number of subscription And so he wanted to have only one filter capabilities or like to find a way to To avoid someone sending you 100 filters inside one subscription Does this say if the filters are an and or It says an and Yeah, if it's an end that's kind of Yeah, I I move the text around but this is basically the text right in here Yeah, so I mean if you put 100 conditions, that means you're not selecting Well, so I think it makes sense for maybe the the discovery endpoint metadata to say If there's a limit to the number of filters you can specify per subscription Right that way so that way at discovery endpoint could say hey, this this is this subscription manager only supports one filter per subscription Yeah, and leave it to the implementation. Yeah, I think you're right. It's better Does it say anything about the The filters yet. It doesn't look like it. What do you mean about the filters? Like what what dialects to the do which filters dialects does it support and things like that? Well, yeah, according to what Clemens wrote it says you must support the basic one Right, but how do you know if you can use other ones? So there's okay. That's actually something else Here Where was it? I added some Did you do a different PR? I thought I added something so someone could discover the list of dialects. Hold on Well, maybe I put in the same PR Oh, yeah here I created I created a subscription dialects entry or field in the discovery Or a field in the discovery thing I would just call it dialects Uh, we could I don't care about the name that much. I was just trying to be consistent. But yeah, we call it dialects Actually, that one is almost like we should have an object that is called subscription with url dialects and config I would say Because the more we add It starts becoming ugly Yeah, we can definitely talk about that. Yeah I don't think as well Is that you and Scott? Yes subscription url subscription fig Protocols, which is also a subscription, but it didn't get grouped. Yeah, exactly. Yeah, that's something. Yeah, you're right I forgot something about that. But yeah, the protocol is basically The subscription service we can say which protocol Yeah, we can definitely switch all that up cleaning up is always good Okay Um, the spec version also that there is one thing is if we have zero dot three and one dot zero What does that mean? It's when you're subscribed who you should ask which format you want? Yes part of the subscription. Yeah, I think too. Yeah I think Um, it's actually to have a Trying to remember hold on So I have a hard stop in three minutes, but I think it's really Super helpful for me at least to participate in those calls Thank you I wish he had a sample subscribe message someplace. I don't think he does In the subscriptions No, there was a But like this one is complete. It's not yeah Yeah, maybe I put it in the bottom Yeah, so here's what a subscribe looks like I think Uh, yeah, it looks something like that Yeah, but notice there's no Well, maybe I messed up, but there's no, um Spec version in there. No No, but that and we need to put it I might be okay because the If the sender sends it should be doing the the options negotiation and it shouldn't be in the subscription What do you mean by that? When it this when the subscription service makes the initial post It should be asking You know what spec version it wants and so if it's it tries to send version one and that doesn't work it might fall back Something that is supported Yeah, that's why for me it would it would be nice to be in the subscription So this way I don't have to fall back because if I generate one million even and I fall back every time on one million events if I'm not smart What happens when you want to upgrade to the next version but all your subscriptions are locked into the old one But you put a subscription you just update the subscription to say now I want the v1 And on your endpoint the sink is basically managing to the two version now Are you re-subscribed depending on your case? Yeah I think we're getting kicked out Yeah Okay, okay. We'll talk to you. We'll talk to you guys, uh, talk to you guys again on thursday or through the slack channel Bon appétit Okay Bye everybody. Bye. Bye Hi Is this for the server serverless, uh, work group? Yes, exactly. Uh Is it nicola couture? Sorry, I had to stop google uh google Yes, my name is gala couture. I'm uh Mostly just interested to attend out of curiosity. So I'm uh going to Be there. Okay, great Welcome to the call and do you want to appear on the attendees list? uh with Yeah, uh, do you want to be associated with a company? It's free to so No, no Okay, we're doing this on a personal basis Unpaid time Yeah, I think there's a holiday in a lot of countries. So I don't know how many people are actually going to join Like I know in brazil there's holidays. So maybe ricardo won't be here How many people usually attend the meeting? Hmm, we have a pretty small community. We have about between five and maybe 10 people typically in the call But we just changed the weekly calls as well. So Okay I'm from montreal, uh, canada Very nice Was a mute and we have falco. Hi falco Hey guys Yeah, this is the first time That we switched to a weekly calls and two weeks ago. We had an additional one last week was the regular bi-weekly And the cncf calendar was updated. I also sent out a note in our select channel And I sent an updated invite To the serverless working group email list Let's see if people already have it on their calendar. Um, as we discussed last week But we also have a few low-hanging foods, I think for the prs Yeah, I've just been So we have uh Sorry, so we have david Hi david Lots of new names. It's great David, can you hear me or malik? Hello, malik. This is malik. Yes, I can hear you. Hi Do you want to be associated with a company? Yes, I'm from american expo section. Yes, sure Thank you Trying again david David, can you hear me? Hey, and we have yogan. Hi. I think we can Start i'm not sure if yogan. Do you know if k wanted to join today? I will ping him and see Okay, but uh, I think we can start so the whole call Let's start with the oh we have one more. Wow Hello Uh karina, I think you were first. Uh, no, she's not connected yet Maybe now karina, can you hear me? Oh, yes, I can hear you. Hi Hi, is this your first time on serverless workflows? Yes, correct. Uh, Tihomir invited me to the meetings. So thank you for inviting me Okay, and is it correct that you are with redhead? Yes, correct Okay, thank you and we have on key again. Hi. Welcome back. Hi Hey trying david one more time david, can you hear me? No, okay, let's start. Uh, so roll call with uh community questions Are there any questions to the community to the group? No Okay, then let's get to our first topic. Uh, so We've been discussing a release plan for quite some time and we wanted to make at least One bump in the release because a lot has happened and we haven't put out a new release And we wanted to get one before kubecon now Um, we already wanted to freeze the current version and work on bug fixes Last week, but um, I think we have to get to it now because there are only two more weeks left to, um, kubecon And we initially we wanted to do a 1.0 but a lot of issues have come up and there is A little bit of work going on. Uh, that was also pushing out Critical fixes that we wanted to do for the retries and the error handling So, um, the idea was maybe to do a version that is not yet a 1.0 but something below The next logical one would be 0.2, but I also feel that uh, too much has happened We could go higher. Uh, I think last week we had a suggestion to use 0.9. I am really not We really just want to signal that we have a new version. Uh, so I'm Opening the mic for suggestions So is the question just uh, which version which number? Yeah. Yeah, yeah, because we had a discussion. I don't want to put any Okay, so so something between 0.1 and less than 1.0 Yeah Okay, I mean 0.2 Sounds fine to me the signal new version but I also get the The part about showing that there's been a lot of improvement or a lot of new lot of change 0.5 might be a candidate That's funny. I just mentioned that same number to teomere on the chat slack And teomere also made a suggestion that maybe we could do a release candidate Personally, I'm in favor of really doing an actual release And then working towards 1.0 After kubecon Same for me as well Like an actual number more than a release candidate Okay, so teomere, um Would you be okay with that 0.5? Does it sound good? Yeah, if everybody's okay with that definitely and I can then start creating the branch and and and uh Once we go through the pr so we can the ones mentioned here. We can just do a freeze Until this work is done and then move on Also in the roadmap as well Perfect, um, okay last chance for objections then 0.5 it is um And also we've been postponing a demo on how to use open api function definitions for two weeks now And uh today would be a good time to have it Uh, teomere, how long should we schedule for that? Is it 15 minutes or uh, if I can have maybe about 20 last 20 minutes I'll be happy with that Sure. Okay, great. Okay with you guys um For today's talk Okay, I have to stop sharing right? We've been there last week Oh, do you want me to like do it now or you want to go through the pr? Yeah. Yeah. Oh Okay. Okay. Okay. Let me just see if you're ready. Uh running Or if if you need more time, then let me do the Okay, I'll share my screen and let me just open up some slides that I have One second Uh, I think I have it going on. All right. It doesn't matter. So I I share my screen Share All right, you guys see my screen somehow Yes, okay, great. Um, I I really would like for this to be some sort of interactive type of talk I don't want to be a monologue and if I talk too much which I sometimes tend to do Uh, please stop me and tell me that that I talk too much Anyways, so, uh, what I wanted to show recently basically for people. They're new here Serverless workflow defines and I'll show this language. I mean the slide here What we show when we define serverless workflow, what it is we really define a declarative in a domain specific language Workflow language declarative as it's not represented in code or if l statements or low level code blocks But it is expressed in json the ammo format and domain specific language as in our target domain Is workflows orchestration of event driven distributed services and the reason why I say that is when we see A look at workflows and what they do and the using orchestrating Things using workflows. We really have to understand our domain Which is a lot of times governed by our architecture and things like that and also see how this language really fits Uh, to translate or to express Uh, the control flow logic and the whole workflow language in that particular domain so recently what we made a change is basically Introduced that we're really Specification and standards based for events We define them using the cloud event specifications And we also made a recent change for function definitions or the definition that tell the runtime implementations How to execute or invoke distributed services during workflow execution And we moved that to uh offloaded our Any sort of possibility to find some custom parameters Use some language that is not really appropriate to our domain Or really be carry on some custom definitions The long run long long run will just mean maintenance toward the open api specification Which is hundred times better suited for Defining invocation of restful services. Do we ever could do in our language? on our own So I wanted to show a little demo in this demo We will code a process together and I think I'll process a workflow together and I thought this would Start some discussion material and also kind of let you guys see some things about the workflow other than just Looking at Uh, the specification of reading the documents and staring at the examples So is this something I just want to before I continue Is this something okay to do right now or you guys find this boring and you don't want to look at it at all Uh, I speak now. I mean, I'm interested All right, so just to show you guys, uh This thing is Okay, so what I'm going to describe to you guys is a use case. All right So the use case that we're looking at is in this particular demo patient onboarding for example in a hospital system So you're dealing with registering a new patient to assist in assigning doctor to a patient based on their conditions and also scheduling Appointment for that particular patient with a doctor that was assigned to it. It's a very small use case Use case of course in real world scenarios. You would have a lot more Rules and and and the business logic would be more complex, but for for this 20 minutes. This is good enough Uh, since we said that a service worker is really A domain specific language. We have to look at now. What is the architecture of our Applications and see how workflows can fit into actually orchestrate to solve the business problem one patient or onboarding so In this slide, you will see that in the application that I will show you That will start soon Is that we have three services running that can be completely distributed But the way I have it I have a lot of issues with internet So I'm running them all locally right now. So it doesn't really matter We have three patient services and we have to orchestrate them in order to Solve our business problem on the bottom You will see that in a lot of cases we have different triggers or Applications or services which need to invoke This orchestration process that can be as we'll see also in the demo Web UIs or there can be some particular devices That might be used in a hospital or other the web UIs Where you enter in new patient information to trigger onboarding The way we're going to do it in this demo is we're going to through different UIs or different devices Push cloud events to a message broker in this demo. I use MQTT I'm mosquito, but you can use Kafka whatever the heck you want to really do now our workflow the way we define it Is can be either triggered and we will see as a service So he has a restful endpoint But we really want to be defining our workflow language that we're going to listen to this new patient cloud event Which is going to trigger our workflow execution and then Orchestrate the services that we have available in our system. So that's kind of like what it is And um, I'm just going to go. I don't know from yet. I'm going to go ahead and Just start my application. He doesn't have any workflows defined yet. Oh well Hold on I forgot to do something real quick One sec Well, this is running. I have this on a branch Uh, we're going to look at uh vs code now in vs code. I have a simple maven project And this is currently what we're going to do is run it on Quarkis you can also run in a spring boot Or micronaut or whatever. It's a java-based runtime currently that I've been working on to to add The the the implementation or the runtime implementation for our serverless workflow language And one important thing when you start working in vs code is I would urge you to go to the extensions and type in Serverless workflow and in this case, you will see the first one is our extension This is the extension that we provide and it's in our github repository And it gives you things like code hints code snippets. It lets you generate an svg diagram for both json and yaml Uh formats and things like that So this is kind of a must to have Especially if you're looking at Coding in vs code So let's let me see if this is completed. Yep. So now I can probably start my app Sorry about that. I wasn't prepared really Anyways, this should just take a second So thank you. We started it. All right. So what the first thing I want to show you Is the swagger ui of our application and just like we showed on this particular slide We have the three services. We have them here The endpoint of our patient services slash patients The endpoint of our doctor services slash doctors And the appointment service is under slash appointment. That's the endpoints of this particular services I don't have any workflows. I don't have any orchestration. So that's what we're going to do together This new patient event service. It's just a little service that from web ui You can hit it give it new patient information. It's going to create a cloud event and push it onto and and qtt So anyway, so let's go back to our Jesus again All right, yes code and this is the maven project Because this is a java runtime if if we ever end up having runtimes in different languages This could be a different project structure, but they're under source main resources uh We're going to create I believe this says we do real quick We're going to create a new workflow and let's call it onboarding uh workflow And we're going to use jason now and let's go ahead and start now when you start using Uh this in vs code and get our extension. You'll see you're going to get code completions, right And he's going to show us first the top level uh parameters that we can use for our workflow. So let's give our Workflow unique idea. Let's call it onboarding We can give it a name Let's say Onboarding workflow and at this point we can start Doing our control flow logic. So let's take a look at that the way we Define control for logic and serverless workflow language is basically a number of states each state does particular control for logic assignment or piece Uh that it's responsible for and then transitions between those states So let's go ahead and define our states For our orchestration. Uh, let's give a state a name. So we have let's say Let's onboard State and each state has a type. Now, you will see that currently in our specification We have nine different types and each one again irresponsible will do some piece of control for logic that that It's assigned to do since in our, uh Onboarding business requirement. We have to wait on an event or new patient event. We're going to use an event state So once you define a type the extension is going to give you the parameters that are associated with that particular type So you're not going to get parameters for different types of states So in our case, uh, we are looking for a parameter called on events. This parameter really means that okay, we define the events that we want to Wait for and then the actions. They're going to be executed once we receive this particular event. So in this case we have Uh an event ref. Let's call it new patient event All right, and then what we only have one now you here you can define multiple you can Define joins and things like that whether multiple events can arrive together if you need more than one If you just want to act on one, uh The actions are associated with singular event and this is what the case is Then we define actions the actions in our case are really invocations of our distributed service or the three services that we have available in our demo So for that, let's define our function reference And we're going to give it a reference name. So this is the first so the first, uh Uh service that we want to invoke we can give it a name, let's say add new patient to System and if you see so far, this is all logical names. These are the domain specific Description of our services that make sense to your domain Uh at your company or your projects are you using there is nothing special Here so now we want to I have two more and since for onboarding I have to first add a patient then design a doctor and then, um Schedule the next appointment. We need to execute these functions in sequentially But you can also in these actions say that you want to execute actions in parallel as well So the next one we want to execute is let's say assign doctor to patient All right, so we got that And the third one we say we say schedule patient And this is really it with one single state where we're able to describe all of the control for logic We're waiting for the particular new patient event We want to execute the three or invoke the three services sequentially The only other thing we have defined in our language is we have to tell the workflow Which state is the starting state in which state is the ending state as far as ending workflow execution So we just since in this case we only have one state um Oops Uh, we want to there are different ways of starting workflows There is a scheduled way and Jurgen knows a lot about that he will help us with that But in this case since we're waiting I went we just have a default start And on the bottom for example, we can define that this state also ends Uh workflow execution And again, let me show you this too If you're interested We can uh create an event when workflow execution ends We can terminate all the threads like if you have some parallel state running branches still in the background or different threads Everything will be killed or for us once we perform the three actions or invocation of our services We just want to end the workflow execution And see with like 30 lines of yaml code. We have defined this or I mean jason code in yaml would be less The only other thing now is that when you have to find the control flow logic We have to give our runtimes a little bit more information About the event new patient event and about the services that we want to invoke So for that what we have is For events we have an events array And this contains our event definition now Right now we're defining an inline But the language itself defines also that this can be a string type where you can offload you can define your events and And function definitions and separate files and reference them here so they can be reused between multiple workflows, right? So in this case what we're going to do we're going to give our one event a name now. This has to match Uh the declarative or the domain specific name here And at this point we use um cloud events context attributes, so we have a type Attribute that has to match The type of the cloud events format of the event that comes in so let's say we call it New patient events for example type and we also want to have a source parameter. This is the parameter that defines Who produces this particular? uh cloud event and One cool thing that you can do especially when you're using message brokers and stuff like that and we have in our requirements our We have described we want to be able to Receive events for multiple sources So instead of defining this event five times each one for each different device that we have One thing that we can actually do is say new patient, which is our topic Uh for our message broker that will receive events And we can just put a plus sign here and this basically means that we want All the events on all their message broker topics there Let's say we have the example of new patient slash web new patient patient slash device x device y All of them is actually going to trigger our Uh instance of our workflow execution. So that's really it for our single event The last thing we have to do is define our functions Our functions are tell the runtime a little bit more information on how to exit actually execute The three services that we want to invoke. So let's go ahead and define our first function You guys stop me with any questions if you guys have any questions, don't you know, don't I'll go off otherwise forever so We have a first function definition And we talked about functions being We use the open i API definition. So we have an operation the parameter here And if I go back to my web page, you will see that things like quarkis and micronaut and swagger and things like that allow us to We don't have to uh hard code The open i API definition, sorry I have to move Um, but it will be generated for us So in a lot of these new types of architectures and and things like that You don't have to deal really with the overhead of Generating this open api stuff yourself. So what I have here is I also have the same thing in our Project but in jason format. So I call it services those jason So what we want to do is in our operation parameter give a uri in this case It's a relative path to our open api definition. So it's Uh api slash services dot jason And then what we want to do is give it a unique identifier of the operation Of this service that we want to invoke. So if you look at our open api definition, we see under Slash patients, which is the first service We have a post operation here that we want to invoke and its operation ideas called add patients. So we're just going to Where's my workbook? All right here We just want to give it that and that's really enough information for the runtime to know exactly what needs to be done in order To execute this particular function. So the only other thing I'm going to do Is create two more one for this one And for this one, it's assigned doctor to patients. So it's our doctor service We look at the post method assigned doctor. That's that And our third one Is our schedule patient appointment service Which has to deal with Where is our appointments the post method is Schedule appointments. All right, and this is it. This is our workflow definition. There is nothing more to it now one cool thing with Serverless workflow via scope plug in what you can do is we can see if we can actually visualize this particular workflow And right now what we have done is we have generated an svg diagram From our jason definition. The same thing can be generated from yaml as well And this looks very simple. It just uses a state uml diagram We can see we have a single state and the border color you're seeing the legend Uh, it matches the type and we see that Our event state waits for a single event called new patient event All right, so one thing I have to do now real quick. I'm sorry since we added the workflow. I have to just restart Uh, my app in order for it to get picked up and this really only takes a couple seconds. Any questions so far Yes, one thing I know this is No, please go ahead Yes, I have a question. Um, you apparently associating functions to Uh, to the different steps. I understand that now. Let's say that I'm more I'm trying to improve my my workflow And um, as a result I'm developing a new function How would I? Uh, and you know, obviously the function is already deployed and possibly running And but I would like to test my functions. So what what would be the approach to do that? Do I need to yeah well It could be in my opinion multiple approaches. Uh You could have workflows or develop just like services and I was going to show them as well Workflows also have a version parameter, which I don't have here. You can version your processes test different ones And the cool thing about workflows are Right now is they're not separate as as your code So just like you will test out your different version of a microservice that you're deploying go or python or whatever The workflows are really the same Uh, the world of this monolith type of workflow deployments where you click a button and I don't know what happens is over And I was going to show you guys actually that right now I redeployed the application and if you look at the swagger ui Right now you will see we all suddenly have a non-boarding service And if you look at our workflow definition, this is the unique id of our workflow So with this modern type of workflow orchestration is You really write your workflows within domain specific language rather than code But you deploy them just like any microservice that anybody on your team would write and deploy So your workflows themselves, even though they define some sort of a part of a solution to a business problem or Really then can be deploy the services and be used by other parts of your teams that let's say Have onboarding is just a part of their business requirements Just like another service that you have deployed in your system And I think that is really kind of like a very important feature right now workflows that there is really no separation between What we call a microservice written let's say in code and deployed on a container or cloud platform or you know a workflow at the end you really don't know right? Okay, let me be a little bit more specific. I understand what you're saying and that makes sense For example, there is a concept of a B testing when you deploy some new Version of a new containers, right? So the way this is done. I mean after you need to play with the routing of the queries Uh, possibly here writing of events again, I don't know exactly how that would be done Essentially, I would want to do some a b testing and I would say only my request or my event So I don't know how to do that either. Maybe I have to create a different you guys. I don't know Only my request should go to this particular workflow And the the people that are currently using my infrastructure. They still they still should be using The workflow that that is in place now Right, but only for the new workflow that I'm trying to develop myself because I'm the developers I want the the routing to be slightly different Is this something that you can address at your level? It can be addressed possibly at, you know, uh, I thought the levels but definitely one way We're addressing this in this particular Java based runtime is via versions So if you if I added a version here Oh, sorry, I'm typing standing up right now Um a version And you can write let's say 1.0 This will be deployed under the endpoint would result in one one underscore o slash onboarding So you can have multiple versions of your workflow running It also you can switch out Per the language definition the function and event definitions So you can keep your control flow logic the same But here instead of having events one thing you can do is say events And you can actually say source Main resources abc.json or yaml So you can even switch those out one can be the events for your Deployment system production what some can be also for your development or testing environments and of course we are looking for contributions in this area as well Uh, because you seem to be an expert I think it would be really nice if you can look at what we have And see what kind of improvements we can make on the language level to make it easier for users to do exactly what you're describing it Does that make sense? Yeah But anyways, um any other questions? Okay, this is Malik here. So you said, uh, what is the question responses for this this election? he Understood like implicitly not even specific explicitly I didn't understand the Input input the input from event a to event b to event c Yeah, yeah, that's a good question and and this is one cool thing about Uh serverless workflow is that you don't really have to if you see my function definitions And also my event definition here. I don't really have any parameters defined, right? And this is because by default each state holds its data So what happens actually here is when we receive the new patient event The payload of this new patient event is going to become the state data Now by default through the specification Uh, if you execute functions, you pass it the entire state data And this is what our workflow is actually doing. However, when you have a function Ref you can define parameters explicitly. So here if your function, let's say, you know from your Open API definition takes in two or three or five parameters You can let's say we could you also define it like this, right? And then you can give an expression, which is a json path expression The query is your state data or in this case the payload of the new patient event Which became the state data and I can just say for example dollar sign dash patient So you can use expressions to find define parameters as well So what happens after each action execution the results of this execution of a service Will be then merged with the state data And then the next function Execution is going to either receive the entire state data as as as payload Or you will you can again define your parameters yourself. But because for this demo Each service that I've defined can just take the entire state data as it comes from From the new patient event. I don't have to define anything So, yeah, yeah, does that help? Oh, yeah, that's good. Thank you No, yeah That's a good question. So just just to end this demo. I'm sorry. I'm probably taking way too long Now let's actually see if we can run this demo Here I have a very simple UI. It just has a form. It's where you enter in Let's say somebody working at a hospital on your patient We can say his name is let's say Michael And this guy unfortunately has breathing Problems now when I click on here We're going to hit create a cloud event. The cloud event is going to be set on our new patient slash from web topic mqtt And it's going to trigger workflow instance And let's see if this actually works. Whoops. Why did I get to I don't know right now? But it doesn't matter. So we'll see we onboarded on Michael He has breathing problems. I think I clicked it twice. Sorry And so this is our first execution of our first service or patient service We are workflow to store the patient or system This guy this oh the appointment service didn't really work. Just I don't know what's going on right now But anyways, and we didn't really get a call from the third service But I don't know this work last night and I'm getting some I think also your workflow definition the function reference Should be there's a table here there in the function reference See the first one is a signed doctor to patient, but there's a Is that right? Which one? Yeah, the line line 43 assigned doctor But the operation is at patient Is that right? Oh, no, this just Matches this guy right here They seem to be out of order Yeah, it doesn't me doesn't matter, but this actually worked. I can just check it the sign. This is bad now schedule appointment, let me just see add patient or is it add patients Should add a new patient to system the operation is Yeah, the functions and the operations are mixed up, I think Which line? That should be assigned doctor and line 48. Oh Sorry, that's why our third one wasn't called Yes, thank you guys so much. I apologize So this is correct now Yeah, thank you guys. Sorry. So let's just go ahead and restart this guy and let's actually run the demo correctly Thank you guys Are you storing these data in anywhere in the database? Right now, no, but you came for the simple demo. I'm just have In memory, okay in memory. I have an application scope class the stores all this stuff in there So, yeah, just the demo. So let's go ahead and do this again So let's Michael and he has a breathing problems Woo, there we go. So we successfully executed our three services in sequential order as per our workflow control flow logic and the only last thing I want to show Is the other devices? So here I have A mosquito. I'm going to publish directly to mosquito topic new patients from client And we have a patient of named new patient from client to make sure it's comes from here And he has a condition of irregular heartbeat. So when I send this directly This will be converted to a cloud event and should trigger also our workflow instance So let's see if you actually did it if I refresh this page And it seemed we didn't oh, I have something wrong. Didn't even send it All right, let's try here with the yeah, there you go So now if we send it. All right, here we go. So we triggered our Uh new workflow instance. We had this event directly that was pushed into the MQTT topic and here is our new patient. He was assigned to some general physician And the scheduling service scheduled him for the next appointment So, uh, what's the question about the um, so You copied this swagger ui into your local pass and you're referring to that file locally But typically the open api spec would be hosted, right? Yeah. Yeah So when you have subsystems, uh exposing api functions How how typically is it to have um this swagger ui definition with with a hosted service You mentioned or what do you what are you using to generate that information internally? uh Okay, sure. So what I showed you guys earlier, uh, we have Uh, the new kind of like things like quarkus and spring boot and things like that once you deploy your services A lot of these things generate the swagger definition or the open api definition for you So not only can he generate you the open api or the swagger ui so you can visually see what's going on You can also hit an endpoint called Open api And you see it just downloaded a file for me and here is it is. So this is the same thing that I have locally in my project Uh, but this is uh yaml. So in my workflow, I could have reference Instead of saying api slash services does jason I could have actually had a full path To my open api endpoint You see So at that point the runtime implementation would get the yaml open api definition Uh parse it and know how to execute to involve this particular uh and particular operation on this service Does that help? yeah, I think that was also um the The reason why we wanted to Also have this demo why this should motivate um that the use of open api is not that difficult um I don't know. Do you think we should? Reference or endorse any of the libraries tools or is this a swagger io library that you're using Yeah, open api has a bunch of different tools for many different languages Uh, since I have this java project. I'm just using the built-in stuff that quarkus has for me I'm not adding anything special. So I'm just using the quarkus open api Extensions and basically everything built in spring boot really has the same stuff And I'm sure if you're not even in the java space, but you're using like a no j s or Or or go or whatever open api has a lot of stuff for that too I'm not familiar with the tools and everything on every language, but I'm kind of like in around like java for too long to to to do a demo in something else At this point. Okay, cool. Thanks much for the demo. Um, are there any other questions? Yeah, that was a cool demo. Yes Yeah, yeah, just have one question which maybe is beyond what you presented, but for example for monitoring the uh, the workflow, uh, the workflow on gene right For example, I want to know where my events are in which state they are And I've possibly have some matrix about, you know, how much time it takes to go from state one to state two to state three Do you have tools that you recommend to do that? No, but one thing that the thoroughest workflow language defines is a set of extensions If you go to our github repository and go to the specification Project, you will see a directory called extensions And the idea is is that the way we want to define those is uh as Extensions to the to the to the language itself and currently you will find an extension called kpi key performance indicators Where you can enhance your workflow Uh information with information about expected versus actual Uh runtime results such as cost and performance and times and things like that Uh, we're also working on a tracing extension currently Uh, so, you know, we're very dependent on the community, you know So any help on any of that Uh would be huge, you know from you guys if you want to get involved just ping us on On on the slack channel and I would love to work with anybody When you mean tracing, you mean tracing, uh, you know, like, uh Jager type of tracing or are you talking about? Okay, um, okay, because here we're talking about events right monitoring events I mean, that's what that that was what my question was about Tracing is one problem in itself and uh, some people have solved it But maybe, you know, there's still a lot of work to be done. I agree with that Um, uh here I'm talking about I want to have visualization of my events and see, you know What's happening in my workflow specifically on the workflow, right? Yeah, but I mean, I'm sure that if we define an extension that is, um That is very kind of like defines a general structure of Of defining like what you want we're looking for and what your expected values are I assume that you can use it with with the with the services that you have available, let's say on kubernetes or your Or your cloud platforms that actually Allow you to to to obtain this information during runtime And and we're basically trying to work with them as well We can't define a service on our own We just deal with a workflow language But the set of extensions that we write should be able to be used in multiple container or Or environments that you're running this in Thanks again to me. I'm sorry in the interest of time I'd like to move on if there are any more questions Please just contact me on the slack channel or open an issue if it's for the spec and so Okay, um Let me share my screen and get to the prs. So we have Two very easy prs. I believe Um One is fixing an image where the output of the let me show it I think the output of our workflow example was Listing a single oh, yeah a single Value in a single map instead of an array of maps because I think the input was three Is it? Yeah, I think this is better Okay, so input for this was an Array of maps and the output then said it's just a single map But it should have been an array with just one map inside Yeah Okay, and I think to me you fixed it and uh in the pr that is listed here, right? state data filter examples Any objections to merging it? Approved The next one is an ambiguous json pass example. Let me check. So this one was Doing an evaluation to I think derive the is adult property and then do a transition based on that And the let me show the fixed I think if I show the changes, it's easier Okay. Yeah, so instead of this it is changing to the condition that is correctly Selecting elements and then when that could it condition is not null So anything would render the as a result of this query would render the condition true Transition is fired as better than this one and yeah, okay I hope everybody had enough time to review it. It was on for a while Any objections to merging this and also approved The third one is a little bit Yeah So I would have had a question to luka Who is not on the call today? um, this is about The conditions at the end of a state, uh, the transitions and the conditions for it Oh, which one was it to me? Okay. Uh, was it the switch state or was it conditions? Yeah, the switch state Our switch state for both database to event based conditions. So the the issue that He was fixed here was that We didn't have in our language and ability to define What to do or which transition or which condition to take On a switch or if you want to think a gateway When there's two conditions that evaluate to true two or more So what we added is two ways. Number one is the Order-based decision. So if you just have a number of conditions in order The the priority would be the Aligned with the ordering of the way you define the conditions And we also added the ability here via priority parameter to declaratively Define a priority specific this same thing like what bpmn is doing really But to define a declarative order on each condition in order to to to Define what to do in cases when there is multiple conditions that are So my argument last week was that we use order in Many points in specification. For example, the actions list is an ordered list And this would not only apply to the switch state. I believe but also done to transitions And I I can't really find the use case because if we use priority numbers We'd also have to clarify What happens if I have the same priority assigned to two transitions and they both fire This again would resolve two orders. So I'm not sure why we would want priority to begin with But I'll ask that to look Yeah And move it to next week if you Okay, then Maybe we can cover one or two issues Especially those two they are both all the 125 and 135 because I think they're both going in the same direction So the first one is from to me to update the error handling section. I think error handling Includes also what happens if call failed and whether this has to be retried layer of function call I meant like an action And there was also a suggestion to move this the retry definition Which is currently described in as part of the event state to a general section on retries and I think both Targeting more or less the same that is tidying up the error handling and introducing a new Section for it. Is that correct? Jürgen and to me Yeah, and it's my fault. I've been on this for too long and I'll try to get it this week done before we cut the release But yeah, Jürgen has added a bunch of cool information and and input to this and and the retry section right now It's it's kind of like exactly the same as what for example aws provides. There is no more or less That we do at this point But with Jürgen's input it has to change We have to redefine like how we actually handle errors and retries and especially associated with different timeouts in our language I think currently it's not very Well, it's ambiguous. It's some cases. So it's not a small task. So if anybody else wants to help with that I'm all ears So to me, do you think we should do this before branching out or cherry pick from The dev branch then for the version point five because I think this is something we would want in version zero point five, right? I don't know. I think I think just Yeah, just talking about the Yeah, I think the PR will be so big that we might take weeks for us to Make a decision on it But I think point five could be going out with what we have currently and this will be a change for maybe the next Either one or whatever we decide the next release would be just my opinion, but again Whatever because another thing are the retries so maximum attempts interval attributes and the exponential back off Which I believe are very good suggestions And we just need to work on PRs for that But it would be good to branch out the or do the reordering first and then add it To a changed version of the spec description definitely seems like the We don't want to be having people Modifying retries stuff while the documents being reorganized. Yeah, it's either either fix the second to on retries Or or do the updates to the organization of the document? But one needs to happen before the other And the the that second one the proposal to remove the retry definition Um, I just think it's confusing where it's at. So I don't know if that should be A require something required to fix before we cut a release Um, whereas I I feel like the retries for max attempts and exponential back off Those are something that would be nice to be in If if we were picking stuff to go into the into the next cut or not But we also added quickly these the the jitter to Intervals, right? So I think introducing those max attempts and interval attributes would also be An easy PR, right? I just don't want people to start work and then get conflicting Changes that have to be sorted out in lengthy sessions. So Just want to make sure if we maybe want to brand Reorganize to me it sounded as if the the retry definition in the event state really just has to be moved to a workflow error handling section so to have it As a general section and then later we can work on other error handling apart from the retry stuff But um, okay, let me see if I Let's let's take this offline And we definitely do the 0.5 branch and freeze And because this also is just reorganization in my opinion. So it's really sort of a Buck fixing for understanding so people can readability, right And then the retries max attempts interval attributes an exponential back off would be additional features So then do this let's do this shortly after That makes sense okay Manuel I just before we end I just wanted to since Karina is still here I just wanted to kind of introduce you guys Karina is From red hat and and one thing that we really need is like a lot of help on the community side of things for a project And she's like a pro on that So I would like to just say Yeah, come on And just a little, you know, if we have ideas and I'm sure Karina will have how to improve Just the overall community section And how we we interact with with the community and try to get more exposure She can help us there a lot. So just letting you guys know Yeah, exactly. Thank you for the intro and caught me in guys and thanks for the demo today. It was great Doesn't welcome aboard. It's great to have you Okay, and I think for the remaining uniqueness constrained is also Something that we have targeted with the correlation token, but you're gonna you made some good points here and the action any events We have we had an outcome that We would want to separate PRs out of this, right? And then the research to add support to Jason patch schema is something that Ricardo who is not with us today is Working on so this is definitely ongoing And this completes my list Sorry to rush through these. Let's definitely follow up on this And we're out of time anyways Any other business anything pressing, you know, okay And then let me do a final roll call for the newcomers. Um, Do you want to be associated with any company? I am actually surprisingly working at American Express and I see Malik. Malik is here I'm at American Express. Yes. Okay, great. Welcome and David, um, can you hear me now? I can Okay, great. Great. I tried at the beginning of the call you're with adobe, right? You've Yeah, I just switched to my phone. So I was having some audio problems at the beginning Okay, perfect. No, just making sure you're here. All right And Subhan Hey Hey, do you want to be associated with any company? Yeah, I'll check CHE GG Like that? Yeah Okay Then thank you everybody and Hear you next week I think we also have a Subhan here, right? Yeah. Oh, sorry. I missed you buddy. Have I missed anybody? No, I think that's complete. Yes Can you can you share the link to this document? so In the chat channel or something like that. Yeah, it's um, yeah, it's also in the Uh Community calendar of the cncf and in the meeting I invite I share today. Okay.  That's the link It's in the meeting and right otherwise. Okay. I have it as well, but yeah, thank you for the link Cool, then Thanks Thank you everyone. Bye. Bye. Have a great day I just


Gilden Media, a division of recorded books, presents Marketing 4.0, moving from traditional to digital, by Philip Kotler, Hermawan Kartajaya, and Iwan Setiawan, narrated by Jonathan Todd Ross. Prologue, from Marketing 3.0 to Marketing 4.0. For the past six years, marketers whom we met around the world have been asking for a sequel to Marketing 3.0. Considering the dynamics of marketing, many would expect Marketing 4.0 to be in the pipeline. In Marketing 3.0, we talked about the major shift from product-driven marketing, 1.0, to customer-centric marketing, 2.0, and ultimately to human-centric marketing, 3.0. In Marketing 3.0, we observed customers transforming into whole human beings with minds, hearts, and spirits. Therefore we argued that the future of marketing lies in creating products, services, and company cultures that embrace and reflect human values. Since the book was published in 2010, many marketers have been adopting the principles of Marketing 3.0. The book was so universally accepted that it has been translated into 24 languages besides English globally. A year after the book was published, we built the Museum of Marketing 3.0 in Ubud Bali. The museum was built with the kind support of the three princes of Ubud, Jakorda Gideh Putra Sukawati, Jakorda Gideh Oka Sukawati, and Jakorda Gideh Raka Sukawati. Ubud, with its aura of spirituality, is indeed the perfect place for the first marketing museum of its kind. In the museum we have been curating inspiring cases of marketers, companies, and marketing campaigns that embrace the human spirit. The contents are organized in a modern multi-screen setup. In recent years the museum has been upgraded with advanced technologies such as augmented reality and virtual reality. Indeed, a lot has happened since we wrote Marketing 3.0, especially in terms of technological advancements. The technologies we are seeing today are not new, but they have been converging in recent years and the collective impact of that convergence has greatly affected marketing practices around the world. New trends are emerging from this. The sharing economy, the now economy, omnichannel integration, content marketing, social CRM, and many other things. We believe that the technology convergence will ultimately lead to the convergence... Sample complete. Ready to continue?