 So, I started with an implementation for Jenkins as a sink and it's kind of fun, but I do think a lot of things need to be cleared up in how it's looking right now. Okay. So, I guess maybe I'll show like a bit of demonstration of the UI itself. And so this is a test UI this I don't think is the UI that we need to go with there is a lot going on in this particular UI, but it was working for this system so I had it, you know, designed this way. Well, for now. Okay, so I, I felt that, you know, there needs to be a way to map or basically sort of like table, while the event that's coming into what needs to happen inside of Jenkins right because the as we talk last time in the last meeting, Sarah, Jeff and I, we we were talking that you know building a job might not be the only event that we might want to trigger inside of Jenkins so so they should be a way to map or just table out what needs to happen when a certain event is received. So the starting point I just thought okay I'll just maybe start with two or three events and a way to map out would be okay. If so, so right now we also decided to, you know, also filter out events based on whether it's a structured format or a binary format. So this one's working with a binary format but I'll move this around so that we can, we can ensure that if it's a structure format then we'll probably check in the type of the the media type and then we'd go inside of the data of the structure format and then extract the C type or the C type or maybe the C source, but I just do feel that C type would have more information in the path inside of it and as like a cloud event about that particular resource and what has happened to that resource. So event topic I selected a build a job here and this can be like any type which a user can enter org. I just had to start here because I was testing out and it's like much easier to type here and also in the test using postman. And then what I also thought was maybe someone would want to have two or three different type of particular cloud events right so they can have org.jankins.ci.start org.jankins.ci.build something similar like that. And, and then, basically, if all of those headers, or this just not I wouldn't say header I would say C type or just cloud event type or cloud event source, they would build either build a job stop build if a job or any job whatever the user decides so this is up to the user to figure out how do they want to trigger inside of Jenkins because again with multiple events, which are available. And still that we because we do not have a standardized definition for the kind of events and the going back to the vocabulary which is the standardized which we don't have right now we might want to have a way to map and I thought that it's better to give users the ability to do that so anyone who is using this plugin as Jenkins as a thing they should have the ability to configure whatever they want to do inside of Jenkins when a particular event is received. And this is again using a request response system but this is something that I want to talk more about after this sort of demonstration and also just change it to build because again it's easier. And then sorry, sorry, Shruti so when you select their start and build that basically saying that if you get like an event, a cloud event that basically the type is start or build it's going to be the job. Is that correct. Yes, yes. Okay. Just trying to understand why so basically you're allowing for multiple event types to do something. Okay, it's right. So if, for example, maybe not page and maybe let's say. The pipeline. I don't really know but let's just start this is basically a filter is it the for the same. I'm like selecting headers, or the C type not the headers. Yeah, like you're filtering based on the headers is this like, um, like, yes based on the the C type so I have some like filtering it based on the cloud. I shouldn't put header here this was just because I was so this as I said this is like using a binary format so I just put headers because see type is going to be present in the header. But it's on the current type. So, if I was to maybe like, so something like this is received, you know, like dark dark turned on so a person is basically going to like, you know, just put this value inside of the field over here. I'm going to do this as soon as so yes this is filtering based on this particular type, and then based on the type that's received. This is going to give users the ability to choose what they want to do inside of Jenkins and make again as I said I don't know if this is the right way to go. I seriously I just thought okay let's just go like whatever I feel like could be an implementation. So that's why sort of debate based it on cloud event type, but going back to the headers I think it just makes the most sense or maybe we can have source but I just feel like type just makes more sense on what was done. And know how maybe like have arbitrary events here which someone would like to trigger and I had the event topic here because I just thought this can be something. When you're talking about a request response system or just like an HTTP rest based like a request response sync. And it can, it can be a way to think of okay here's a topic that Jenkins is sort of subscribing to and whenever this particular thing is going to happen Jenkins basically does particular or triggers a particular action. I think that makes sense. I think that makes sense in general like filtering the type of the event, then to trigger an action. Then you will need to figure out how to extract which job to trigger right. That's the second part. Okay. Okay. Thanks, Mauricio. I'm really sorry if I wasn't clear. No worries, no worries. That's good. Um, so yeah so maybe I will delete this to keep the UI cleaner and I'll also just have start here, just but in your head, just think of this as start see the cloud event type start. So you're you're so everything kind of, you know, it's cleaner to look at. And then I have this configure additional properties. I mean I did not know what better place to put this at, but what I ideally wanted to do was as soon like as the topic received would be build job, something like an optional block of selecting an existing project would come up. So building a job or stopping build up a job, fire, select existing project. So I did try running a validation on on this particular like drop down and then also on so this is a Boolean field so I did try running a validation but that did not work so I then converted into sort of like a string and it's then it started working so I was like okay maybe this only is going to work for for like a like a string but this is not going to work here. Again that's something that we can figure out moving forward but for now, if a person's you know, and all the logic of what happens when a person basically does not choose job that's just that won't really affect the the whole like experience for the user itself. Um, so I build the building a job and I'm going to select an existing project already kind of select is I'm going to believe this. Wait, where did I go. Okay, I'm really sorry that wasn't. It also jumps for some weird reason and I don't know why it's like the ui jumps but so. I'm sorry. Don't worry too much about the demos I mean as soon as we see kind of like the fields and the data that it's being collected is correct. You know, demos tends to fail all the time. I have two jobs right now I have a test job and I have failed job so this is basically giving the user to enter the job they want I'm just going to select two jobs. Um, even though that's meant to fail but every time a C type of start will be received at at the end point that I have given for this particular like this plugin for the sink. Every time this particular C type will be received here in the header, it's going to build a job and it's going to build a test shop and fail job. I can also configure. I also thought maybe users won't want to do more of you know triggering more action so maybe they want to stop build up the job but they want to have a different type here so maybe this is. Or a dot dot pipeline. So it's something like this and for this they're also going to select an existing project, which is going to select fail. So, again, you know the UI I need to work on this like I'm going to need help on this because this just looks so confused so if I'm okay I'm going to. You know, it's a lot of like repeatables and like I had to put some of this into describable into two different describables, one for this, this whole block and one for this block right here. And then again like if someone has to do another one of this whole event block of you know selecting a type and then selecting an action it's, it can be really long can be a little. I don't think it looks really clear because we already have this Jenkins as a sink like Jenkins as a source implementation and I was looking away to break this into Jenkins as a source and Jenkins as a sink but still remain within cloud cloud events plugin, you know maybe like a sub header. For a line breaks I wasn't able to find it yet, but I'm working on at least sort of like breaking this apart between this is Jenkins as a source and all starting configure Jenkins as a sink is Jenkins as a sink. Anyway, yeah, logically, logically I would say that they are separated right because you can configure one without the other. So maybe even kind of like having two separate screens, at least for me it will make sense. And on the sink side, I wonder why did you choose to put like the event topic, which is the action that you're going to trigger at the beginning. I think that that's just it might be just kind of like the way that I think about this, but I would usually put the filter first in the idea like the idea of saying when this happens right when this event happened. I want to then trigger this thing against this kind of like this job in particular right so I would definitely put closer like the event topic the action and the selected project. And just to make sure that they are close because that's kind of like how I think that people will just go and configure these things. It's just kind of like a mental flow that they will follow. Yeah, I think. No, no, no, I think that that's that's that's just a kind of like a minor detail on how things are arranged. And the next thing that you will need to think about is a way to define. For example, if you want to trigger a job, you can trigger it by name, right. So for example, there you're just saying, just run the test and the fail job. That's fine. But when you want to cancel a job, you will probably need to do it by ID, not by name, right. Is that correct. Yeah, because, because you can have multiple instances of tests running right, you can have multiple test jobs running and you need to decide which one do you want to stop. You cannot stop all the jobs. Yeah, there are certain points in which you might have to give certain parameters based on the sync that. So, you should be able to also pull from the sync and like we haven't reached that point where we are passing the body for certain stuff, but maybe something to keep in mind. So, you should probably look at giving like, you know, test number, as in like the building number instead of the project name. I think that makes a lot of sense. But like, I'm thinking is, like, is there a way that we can, you know, like, because I think if we'd have to give a number wouldn't like a user would have to look at a first. Again, so what the what like the stop build of the job does right now is basically so if there's, you know, the, if I have this test or fail and if it's in the queue, any, you know, any job is if a test is in the queue or if the fail is in the queue. It's just going to cancel the last instance of what's in the queue and I think that's really troubling. But like, if we are giving users the, okay, you go and enter the field for the maybe like the ID or something. I'm just thinking how maybe difficult would it be for a user to figure out what exactly do I want to cancel. That's like doesn't make sense. Yeah, I think build number probably is like, not a great idea. But is there a way to kind of annotate jobs, so that you know, the latest jobs of a certain kind would get stopped in that case. I think like that's something that I need to look into. But I like again with like stopping the build of the job that was that was one thing because, for example, if a person has, they already have a build running. They have a failed job running. And if they have five or failed jobs in the queue. And there's this certain one with the that was maybe triggered from like that was triggered automatically from like some external system. That was, that's the, the queue number three out of the five jobs that you're in the queue. And this is failed job which I'm talking about. And this particular failed job number three maybe has some additional, you know, like particular, let's say, scripts, or maybe particular other changes. So I'm just thinking maybe we can, like one way can be to have this information passed down from from the event body itself so like the event body is like okay this particular job was just like maybe like I'm going to take it all. So this particular pipeline was started. This particular pipeline is using this this this, like maybe like four different scripts. And each script is basically like each script maybe has an ID, right so whenever we're passing that and we're like, Okay, we want this particular script with ID number three is present in failed job number three. I don't know how feasible that is because, you know, that's again, first, it's kind of like tightly coupling things. And the second is, it's not always guaranteed that we will receive the event data that necessarily is going to link the particular job that's in the queue that we want to cancel with. With just like jobs or someone says because as I said, this just cancels the last job in the queue so there are five in the queue is just going to cancel the fifth one in the queue, and the other ones are going to run. So it's a very interesting question to think about. And like something that I wanted to also mention and talk about was how can we exactly figure out which, which job would need to be canceled out of the multiple which are present in the maybe in the queue or maybe already executing. It really depends on the use case that for some integration purposes, you might have been you might be able to get that ID from their body right. I mean, I guess that that should be kind of like the approach if you get the ID in the body you should try to parse and get it and try to just stop that job. You will just execute that default behavior of stopping the latest one or something like that. Because if not it's going to be very tricky to figure out which one to stop and you always will end up like stopping the latest which might be started by some other action right. It might be just started manually by someone else or by another event or whatever it's happening in the in the in the ecosystem that case. Maybe having kind of like these two parts one trying to read kind of like an ID from the body and if it's not there, then just stopping the last might be good enough for now. Yeah, I think that's a good way to implement it. And again, I think it's just giving you just giving users the ability to sort of control how they might want to stop the build of a job. So another thing that Marisha mentioned was the event topic. I, I put it here to start because I thought when you know there are multiple C like cloud event types or someone has added here. And when it went topic was at bottom of all of this, it sort of looked confusing but it definitely makes the most sense. When a person first configure if I want to, if I receive type of this type this type and this type I want to trigger this action. So rather than want to trigger this action and junk into currency so on so. So, do you think that it would be okay for person has maybe like five or three or however many cloud event types configured here and then have the event topic. I think so yeah I would I would definitely add the filter first. And not 100% sure of having multiple event types that will make it more difficult for you to pass right like if you need to pass the body, you will need to check the type first and then decide how to pass it, because different kind like events might come with different bodies So, but yeah, I think that if you want to leave that option of selecting multiple filters I wouldn't be against that. But yeah I would just put the filter first, then the topic then the action and then the project where it's going to execute basically. Maybe it makes sense to explore the sea so adding like filtering off like different headers itself. I mean the, okay I'm just going to call the main parts the headers, but maybe make sense to, you know, figure out adding if the adding other headers will also help. I feel it would definitely give more flexibility, because the type can be the same from time to time, but you know you would like to pass also on like the subject or like the source from which it is coming in. And with things like the source, I think it is interesting. The sea source in tecton should ideally give the Morris you do think it should give the server endpoint as well. The sea source. The sea source. What do you mean when you're when we are sending when we are sending cloud events or when we are consuming like tecton sending cloud events, should the sea source contain the endpoint. Sometimes that's needed sometimes that's not usually that's kind of like this service that it's a meeting that right. Yeah, so in this case that that event is being emitted by a desk run that it's called girl run right that's the only thing that it's saying it doesn't really matter where was generated. For me, I don't think that that will be needed of who is emitting but it can that can be part of the that can be part of the body of the event as well, which might be something that tecton is doing. I don't know. Yeah, with the thing with task runs is the name keeps changing. So, yeah, maybe, maybe we can give a generic name in the beginning and the extension which is added can be, you know, it could be kind of like grab at that point. Just checking for some subtext. Yeah, that can be an option. Yes. I do not have any strong feelings or that. So are we saying that. Like see type and see source. Maybe like function together. It's like, is that so so just as a way to maybe add more metadata and then give more ability Jenkins to kind of figure out what to do that it might be a better option to have see type and see source. You're like user should be able to, you know, pass with different things as well, not just see. Yeah, I'm thinking like, I'm thinking that, you know, if, because again, like, I just kept one of those because they see source and see type fully like fully do not come away. All of the information so we will, if we are like looking through the bond, if we have to pass through the body, we will have to pass through the body. If we have the see source and see type present. Because yes it might be able to say that it's like this particular task runner was this particular type with of this of like the cloud event that's received, but it does not fully contain the information that might be needed like the additional information so we will eventually have to go into parsing the body so I'm just thinking if you know that you'd be like okay let me enter the type okay then let me also enter the subject. Because, like, again as I said we might have to pursue the body and get that information anyway. At some point we will definitely have to pass the body and get information from them. But, but the question is, like, how, like the use is should the user be able to pass any field for checking, and then you know triggering the Jenkins job. So, if right now you only can see type right so maybe maybe it should be like, you know, you should the user should be able to, you know, configure which, which key they want to check in in the request that is coming. So, sorry, in the cloud event that is coming in. So, here as you said like add C type, maybe it could be something like, you know, add, add filter. So, and then in the filter you can give like which key and what value are you looking for in that key. So, that is that is a more flexible way of doing things I feel. And, and when you're giving the value you can the user user could probably give like a rejects or something which would match certain elements in the value of that key. So, whether it be like C type C subject, anything, or like something that is part of the cloud event data itself. I think that would be something that would be a lot more flexible. And it would definitely like allow us to do things like you know, probably like past parameters to like from tech on to like Jenkins. If tech on results are off, like we get certain tech on results. And we would like to, you know, pass those tech on results to the as parameters to the existing job. So, we would like to do things like so at some point. So, just just creating that flexibility is quite important. Yeah, yeah, I think that made sense. And so, there are two types of cloud events, which can be received inside of Jenkins. One is this binary structure, or like, and other is the structured format where everything will be present inside of what we can say the event body. So, where should a user also maybe enter a field about whether this is, you know, a structured or JSON format or should that be done inside of this plugin because we shouldn't make the user choose it. We should just do it by ourselves. So if it is binary or structured format, users shouldn't have to learn what binary or structured format is because we know that we are abstracting that for the user. So, we should just take whatever events come in in the back and we should check if it is binary or structured, and then based on that we carry out things like the user doesn't need to know that for sure. Yeah, that's a very good point. Yeah, I'm just thinking of sort of the, the validations which would be needed in in the UI itself. So, as I said, like what I wanted to do was, if, if the topic is build a job, then automatically like give user the ability to enter an existing existing project, but it was really hard to figure out how to do that. So I'm just thinking. And we sort of like, like give user stability to like enter fields depending on what they have selected. So if they, I don't know, I'm thinking, I don't know, I'm just thinking out loud. Like I'm saying that we might want the type or like how give users ability to enter one or however many fields to look for as a filter. I'm just thinking of like, how can we give user or like how can that be sort of automated inside of you. But I think like what you guys have said, those are very good points, and I'm going to iterate on making those and like changing to, you know, just having or giving users the ability to decide what can be the filter here. For the filtering, but I think we can use, I don't know if that's a Java version of it, but there is something called common expression language, which are tecton users to filter stuff. So it allows us to like match expressions, different kind of expressions and, you know, do a lot of different things with the incoming data. So just master key and the whatever operator you want to use and then the values. So kind of doing things like that. And, but so you could probably check out like me put that here. Um, like in checking is more, maybe sort of checking in the UI so that flow, but it's not going to make sense now what I'm saying I think maybe when I start again not duration, it might make more sense. So for, let's receive request. So this is the, the building, the checking, and this is what sort of like doing the, you know, just like matching if this is the header and do this and stuff. Um, but, but Okay, I'm not making sense at all right now. It's okay we will move. You are making sense you are making sense just just just say I'm not just saying like so so if a person selected for example if they selected a stop build a job right and the field, which is event topic inside of like our jelly files and inside of her Java class. If this particular like event topic is stop build of a job then trigger Wait, just let me do this and automatically like trigger this particular field. So as soon as a person selected stop build with the job because this is already like if the person is wanting to stop build of a job it has to be an existing job. So automatically triggered this field. Like, like pop up, or maybe like automatically pop up or figure by itself. So it only really happens when I save it so if I have any logic like if the event topic is just a little job, then select existing project should be true and all of that really happens when it's being saved and which makes sense, obviously. But I'm just thinking when we're adding more of UI how to prevent are you know how to prevent putting a lot of information that users would not have to enter for like select existing project or configure new project they If not need be here, but they are only because there's no other way that I could figure out how to how to put this elect existing project so maybe a person wants to build a job but they do not look at select existing field at all and they do not understand what to do where to go. So I'm just thinking of automating each step and I looked into like scraps inside of jelly I looked into other. You know like obviously the condition for grabbing inside of jelly but that everything works when it's saved. So, I went with the optional blog because then the users would not see this whole like text field when they do not have to enter it. You know like configure a new project build a building a job does not require this feel for configuring new project so that's why it's unselected so user does not see this additional UI bit. So that's what I'm thinking when we have a lot of you know adding keys and values and also adding, maybe just, you know, about like additional, I don't know like metadata or any, any of that stuff. How to reduce or be minimalistic in terms of the US so so user is not confused about do they need. Your question. But so, like a nice way to think about UI for the Jenkins configuration would to actually just get a pen and paper and try to write what is the most simple yaml I could write for the configuration. So, that's that's how high how I would think about it. And why I'm saying that is because I remember, I think it was Jeff, who said that probably we should have our own dashboard in for configuring cloud events, and I kind of agree with that because from the looks of this it feels like it will scale to such a level to take over the entire global plug in configuration, like 90% it is possible that if people doing a lot of cloud event filtering kind of stuff to, you know, trigger the jobs, there might come a point where it would like 90% of this would become 90% of global plug in configuration would become just cloud events. So, I think it's, it makes sense to invest some time in, you know, figuring the UI for that. And I'm also thinking, would it be, would it make sense for now to kind of. So now that we have an idea like what, you know, the internals look like that. Okay, we get a cloud event, we, you know, are set, and then we kind of are based on that. If the parsing stuff comes correctly, then after that we use some of it as parameters, and the rest of it as like, which job probably could be triggered, like, we can use this stuff and then put into Jenkins job trigger the Jenkins job. That will be like our life cycle, right. But I think it's at this point in our project, it is probably a good idea to take a step back and like kind of see how this works out all in London, because at some point in time we would have to do that. So, right now we are focusing completely on the, what do you call it, the working, it's the business logic of all of this stuff. But I think it is, it is a good time to kind of take a step back and you know, figure out what configuration would be like, you know, best sort of configuration for this. So, you've done a great job, and I think the next step probably like this week, what we can do is kind of figure out what, you know, configuration looks like for this. Yeah, I sort of just say I like that because the UI needs to support what we want it to do right so maybe focusing on the UI before we're sure we have that nailed down as isn't the most productive. Yeah, that makes sense. And like the config, like configuring just getting information from the UI thing like that takes more time than just configuring the plugin. And then when we say the config part and put it in, or like it sort of abstracting away this whole, you know, how do we get this information. Like what exactly, what exactly do we mean like in terms of putting it into a YAML file, is it for config as a code but or is it like completely different just just for working on the functioning logic of the plugin rather than working on. So, you know, the fun thing about that is that we can double it as config is code at some point. But if, like, it just happens to be a good exercise to, you know, just kind of put things down in YAML sometimes because YAML is simple. It's got arrays. It's got key value pairs. And that's it. And, you know, when you think in terms of these things, you will come up with a UI that is simple enough, yet useful enough and it has like enough repeatable pieces that the user can, you know, easily think in. It's probably like this week what we can do is we can like figure out like what that would look like and like just under cloud events. So you got like this entire big cloud event thing. And then under that probably you've got like, I'm thinking in YAML right now. So you've got like the cloud events. Okay cloud events colon, I go down, double space, then I'll write syncs, then colon, then I'll go down and I'll start a list with that, right. I'll start a list. I'll put a dash. I'll say, like, name. Yeah. What is the name of the sync? And then something like that. So configuring Jenkins as a sync. Do I want multiple syncs here or like just one sync? So that's how I figure it out. So to start off, we basically just convert this stuff that we've done right now to the YAML and see how well that works. And we can make changes there. And as we are making changes that we can come back here and tweak this to fit the YAML and kind of kind of go back and forth on that. Why I'm saying to like do this is because it is, it would maybe work at some point like simple enough and like quite efficient for the user. Yeah, I think that's a really great idea. And it honestly sounds fun or like funner than, you know, like doing a lot of this. I really don't know what you're going through right now dealing with all of this jelly, because I know it's not easy to figure this out. And it's not even Java. It's just XML of some sort. Maybe doing this exercise could also take you out of this rut of jelly that you probably have been trying to figure all this out. I don't think just it will help clear your mind a lot about these things. And obviously we can at some point come back to jelly. And Jeff, correct me if I'm wrong, but a lot of configuration these days for Jenkins is better done through configuration as cool. And just just for the fact that it's simple. And you know, I can look at it and okay, this is what it's doing. So it's, it's just that So I mean, I think that that is the best way to configure it. And I mean, I don't think like any development tools, you know, that that's you often configure them with with YAML or JSON or something. I think that most plugins, though, do have to have some UI as well. But the other thing is if we're talking about some sort of a standalone UI that that's not part of the system configuration settings I don't think that has to be in jelly I think it can can use HTML and JavaScript and stuff so that might be another reason to kind of defocus the the jelly stuff. But definitely any any new plugin needs to support configuration is as code I believe I mean it's not a hard requirement but it but it really should. Jeff, are you saying that we can we can use this as a JavaScript for the front end? No, you can. Yes, you can. And but I think that if we have a standalone UI where it's not, you know, not part of an existing page like this it's even easier. And you can do it on the system on the system configuration page but it's kind of hard to figure out how to how to plug it in but if it's a standalone thing that's totally separate then I think that we can use anything we want it's basically pulls up a web app and a web app and then you know there's like Java bindings and stuff. Like any examples of this so like any plugin which might already use this kind of, you know, standalone. So, well, I so I'm not sure what is going on with the Jenkins UI right now. At one point, they were going to use react and I actually mentored a project that that was was using react. But it worked well but I think he, there's some issues with compatibility because there's like which version of react is Jenkins using. And I think I had him do a react like a react sample to like a kind of a kickstarter thing. But, but we so my hesitation is we did that at the time that that blue ocean was going to be the UI and it was react based and I believe that blue oceans not being pushed forward and and I'm not plugged into what's going on with you I so I don't know if it's a different framework now. Well, we don't have to use a react, I feel. No, but it would be just like simple JavaScript and you know, just simple HTML. Yeah, I believe that's probably the case. Um, so so one, like really old and sort of crusty example is the thin black then backup plugin. So it has like a separate web applet and I don't believe it uses jelly. Yeah. Yeah, I had logged into the, like the thin backup plugin and also a couple other plugins. So some of them are using Ruby, some of them have like this scripting section inside of jelly, which is doing, you know, a lot of maybe works with displaying the, the list or doing the work with what happens when something is submitted. But again, yes, that was not inside of global config. So the global config works very, I think like differently but also very attached with how Jenkins saves and from like how jelly saves information inside of global configuration. And that's why scripting here was not working. I did try using that. But if, yes, maybe the next option is to actually move out of global configuration. Um, and I did try another like the clone that I have and try to using the extending and working with management link, but I wasn't sure if this is working so I stuck with global config, but you guys are really right on how this is becoming really a hefty task for users or just to, you know, think of and develop. So I think it's really the time to move away from global configuration and think of other ways to achieve the same effect and reduce this overhead of just designing. So I was wrong that the thin backup does does use jelly for the UI, but it doesn't. It has it's like like separate configuration applet. So it's not it's not part of this global config. So, I mean it solves one of my suggestions, just to move this into a separate separate web app. Yeah, the scripting with jelly. I looked at like I look at a lot of plugins, just to figure, you know, this repeatable as the additional properties and the auto complete. I did find a good amount which we're using like JavaScript scripts inside of jelly and this is really cool and then I did try and permitting it inside of global configuration but it wasn't working. And at that time I had some things down so I'm like, okay, let's just first see if this sort of system of, you know, having a filter and then having the particular like an event that a user would like to trigger if this works or not but if you're sure that this kind of a sync of, you know, having a filter, having or giving users ability to enter an event topic if this works, then I'm going to move away and spend my time in designing it in the simpler terms with YAML and then config is code is added to this plugin and it does work. I checked it, but again, you know, someone might not look into that someone might come to this plugin so I don't really know how. I didn't know how to simplify it, but I do know now. Yes, moving away from moving away from those. I sent a link to the GSOC project that I worked on that has the React-based UI. Unfortunately, it's still a pull request because after the project was over, I didn't have the student merge it, which is my bad. And when I tried testing it, I found some bugs and so I fixed some of them and it still has one, but that's an example of something that has a separate or that uses something other than jelly for its UI. And again, I'm not necessarily advocating for React, but it just shows it can be done. Thanks, Jeff. Yes, that's going to be really helpful. And even if they're not using maybe just like React, we can look into just plain JavaScript and if anything that works and is better than this, I think. For me, it actually looks really cool. And complex for, you know, we can get a lot of information, but not to actually configure. So what do you plan on doing for your next task? So the first thing is looking into ways that this can be moved out of global configuration and how the whole, the jelly itself can be simplified with maybe either using scripting or with going with JavaScript or framework, React, whatever works. And also, as you said, I think simplifying it in thinking of it in terms of YAML. I'm sort of visualizing it in my head right now and that looks really awesome and something that can really help figure out stuff on how it can also be presented with the UI, so that and then implementing the changes for just the filtering part. It works in a more sort of open and agnostic manner. Those are the next few big tasks. Have you got a chance to look at, like, have you got a chance to run cloud events with TechTone by any chance? No, I haven't run them. I've just been reading their docs. And I'm guessing you're currently working with this locally, right? Were you able to run this on Kubernetes? No, I was actually thinking about this and I was like, I should also try running that. And yes, I'm running this locally on my system. But that's a good suggestion. I would suggest checking out the Sokai Appo by New Scott, I think. So that's his GitHub name. I'm checking out the UI for that. It's just very simple and there are a few things that would be nice to have which are quite agnostic. And, you know, that gives us like something to work with because it's made by someone working in Knit. We have a good idea of how to pass this cloud event stuff. I think that's a good way to, that's a thing that you could do. But I would like, I would like you to just take a probably like a step back this week and kind of instead of working on anything new or like improving something, just kind of do a good review of different things and like take inventory of, you know, how cloud events are being used across and how things are being passed because I think at this point in our project, it is like possible to kind of get off track maybe a little bit or like, you know, just not off track but like, you know, get a little lost which can which can be detrimental. And like we start solving problems that don't exist or like we start extending things like which are like kind of out of scope in a way. So I think this week would be nice to just take a step back just look at stuff what other people have done. And maybe next week we can come and then you know discuss these things and like and start with a new perspective, or at least a better perspective. Yes, that's, yes, those are very good suggestions and honestly, like, good ideas for the work that needs to be done and also we have, you know, two minutes going beyond the meeting time. And I really appreciate the suggestions and all the help for, you know, like the plugin and the UI and all that stuff. And there was one more thing but I think we, this is the more prominent thing and just the sync implementation. Again, when we were talking about it's the next week, I think we can talk about that as well there. Yes. On, we'll be looking at, you know, different implementations for cloud events and also maybe just just event agnostic systems and see how they're implementing stuff. That sounds good. Probably, I have a feeling we should probably do another meeting but I'll just stop when you when you're in person or like on the chart and if everyone is available, you could probably do another meeting. Sounds very good. Excellent discussion today. And thank you for your demo. I should say. So I think we can wrap up and thank you all for being here. And we will see you next week. All good. Hey. Thank you. Bye bye.