 So, so as I said, like, you know, pretty related thinking that, you know, for something to be truly sort of cloud native and also build upon that event driven systems, how can we or how are we thinking of dealing with maybe transient failures or just like simple network failures and sending requests for Jenkins as a source but also for Jenkins as a sync, how can we implement an architecture which can persist events and also create a way for any source which is sending events to Jenkins sync to really have that architecture where events are not being lost and every time there is something which is capturing the events and dealing with whatever action needs to be taken at maybe like an asynchronous time, because I keep going back to that one thing you said and that was really that really resonated in terms of the architecture was loosely coupling. And if we basically like design a system where it's sort of like an RPC call between Jenkins as a source and whatever sync and Jenkins as a sync and whatever source. And then it's very like dependent and it's very tightly coupled with another service being available especially for Jenkins and sync or I mean a Jenkins as a source we really want that other service to be available when we're sending to do something or maybe when we're talking about Jenkins as a sync, we really want the sync to be available whenever another source is sending and I think its implementation for Jenkins as a sync is way more important than Jenkins as a source, because you know someone really might depend on taking an action inside of Jenkins whenever a cloud event is triggered in that particular source. And I've been thinking about that. There is actually a plugin which is, it's some cloud we pop sub like pop sub like plugin for Jenkins, and it's, I'm not really sure if a public subscribe pattern might work here having something like a simple queuing system might work or if we, if we even want to go that route for now. Maybe just like to hear what your thoughts and that are if you have suggestions. I mean I always thought of, it's interesting this idea of sync and source because I came into the project when I first thought about it was in terms of pop sub so exactly that. There's probably different ways to think about how, how events, how they're kept how you, how much. How can I say this how much you guarantee the ordering of them in many ways, and, and then how long you persist them for. And I think that's a whole series of. A couple of different ways of doing it but I think publish subscribe is would be certainly a good way to start. Yeah, yeah, I think those are very important things to consider. And also when we are talking about just having a published subscribe pattern for Jenkins as they sink. I mean, I like what in in my head I'm thinking what it might look like is, you know, someone is creating a user who wants to use Jenkins as a sink is creating a topic inside of inside of that Jenkins, that that bus, which is going to be different from the Jenkins as a sink implementation or the Jenkins is the same configuration, because I don't really think I'm putting the bus alongside or like the bus or the or just the topic configuration with the actual plugin. And I think that that really makes sense. It has to go. I mean it should come with the plugin but just the configuration of creating topics, which are sink will subscribe to and the publisher will send messages to How do you think that can look like. I think there's a couple ways to purchase it I literally have this data intensive applications open like let's see it is a quick idea that I'm doing this. Now I think there's like a number of ways in which you can deal with how you process streams, how you store streams, like how streams are transported like how are you directly message brokers event logs, and then how you process them afterwards like there's so many different ways to approach this that. I mean, it is kind of like a really an open question because you want to leave it like is that going to be something that's left that we want to leave configurable for an end user or is that something that we decide I guess if it's just Jenkins is something that we do need to decide on and it should make sense for a CIC pipeline, but is that something that should be decided more at the level of like the event seg, I really, I really don't know. What have you what have you been reading, just out of curiosity. Well, I so all of the usually the pops up patterns of design for any event sort of mediator or just a middleware any any service whether it's from Azure or whether it's even a simple thing like a Kafka implementing something like that is, is that usually creating a topic to be configured and and you know we cannot I mean there should be a way that will be open for the users to mention whatever topic it's going to be that Jenkins as a sync will subscribe to but also have have a way of persistence in that bus itself where all of the events are coming in. So, actually, the candidate broker I shared this with. When we talk last in our meeting. Maybe send it over in this in like in our channel. Okay. Okay, native broker or just kind of eventing in general it's also very interesting because they have this live system where all of the events are coming in and then they have triggers which which is essentially maybe you know like like a topic or something that is open for the user to configure that what do they want to do with this with this type of event. But there is sort of that you know middle middleware which is sitting in between receiving all of those topics and then based on maybe the filters are based on the topic or just based on here for Canadian eventing they have they have triggers. Which they say that it represents a desire to subscribe to events from a specific broker. So, for them trigger is something which is sort of like sitting at that level between broker and the actual whatever is going to be working with that actual event. So they're filtering based on the they have different brokers maybe configured with, you know, different sort of maybe metadata or whatever a broker name a broker type. I think it's usually broken me. Yeah, it is broken me. Can I ask you a question. This is super interesting with the triggers because it doesn't just go from brokers just subscribers, the broker emits triggers. And then that's what the subscribers subscribe to. So, so how are these triggers how are these triggers created that's So what suits basically like the trigger sort of sitting at that broker and it's so when we have that trigger it's basically saying that I want to receive event from this particular broker, which is so there is a default broker and I think they call it default. And then there's broker like that someone can create, and you only maybe as a publisher only send events to that broker say let's call it K native trigger. Let's say it's like a pipeline type on pipeline run broker, and I'm sending my events to this broker. And then as a trigger I've said that as soon as this broker receives any event I want to, I want to subscribe to do that. So that's actually creating a trigger, like subscribing to that from a particular broker. And then, you know as as I have subscribed I want to, I want to maybe like take what I mentioned. I'm not, I'm not really sure how they are taking actions with their whole like broker and trigger pattern of a trigger actually sort of not being a trigger for an event but being a trigger for for that that subscriber or that broker is So, so, so is the trigger so there's the broker which is I guess, like some sort of message queue message brass and then the trigger is the logic, is that right it's the logic is the logic of what you do with the different events or what can be done. It's setting to the subscribers, like it has more knowledge more control more sense of. I guess more sense of context in many ways like this thing happen it's not I'm not just giving information I'm just contains more data on what you may want to do with that information is that is that right or is it not as knowledgeable the context is I'm thinking Yeah, that's what, like that's what I understand of like triggers just saying that. Okay, I do want to when when an event is coming into a particular broker with a particular name. I am, I'll send this to a subscriber but there's there so there's filtering inside of trigger so you can you can like filter with different triggers but I wouldn't really say that the trigger itself has a lot of information but it does have information for like let's say the I'm actually looking at I'll send he also sent this one of their their like filtering and how they're doing it. So, so they have like the broker and then they have filters inside of that broker which will create that like that contacts with that knowledge that you're talking about. So, you know, even when you have a broker which is subscribing to a particular which is basically sitting between that publish and subscriber of two different kinds. And like publisher says that you know I have all of these events all of which will go to broker a even inside of that broker you will have like trigger scan filter based on it here they have attributes so we can also have attributes of you know the C type should be so and so the C source should be so and so if that makes sense. Yeah, thank you. That actually does clarify it a lot. Thank you. I don't know if that helps you there. But I think this is a really interesting pattern. I'm just thinking that if we are creating that type of thing between, you know, Jenkins as a saying can any any subs, any sort of publisher know whatever that source is it's very tightly coupled then the whole idea of communication being asynchronous being, you know, failure resistant is sort of like the whole idea is it's just loses the whole thing so I'm not, again I'm not really sure because they're not just you know there's within pops up patterns to their, as you said there's so many ways we can implement this. And the only one thing that I did look into was the the pops up like plug in inside of Jenkins, which is like a pops up a lightweight publish subscribe pattern for Jenkins, but it is still this pretty interesting. So, it's like I was just thinking about what way can we use and how can the configuration look like because you know even the K data event thing. It's using that pops up pattern but how they're creating that topic and creating filters on it is very interesting. I mean, I feel like this little this is going to probably go beyond just, you know, the end of GSOC and also talk for for like creating the best architecture possible for Venderman systems and asynchronous Venderman systems creating all these patterns. I think they take a lot of thought and the reiteration so I'm actually excited to have this conversation and then they have these conversations in the future, whatever we might end up developing. Yeah, I totally agree. I think this has got, you know, the GSOC project project is amazing and your work is fantastic but I think there will definitely be more to work on beyond GSOC and you will be a great person to do it and I do think it has all these like really interesting questions on architecture and how you make a good event driven system that are sort of questions industry as a whole or is grappling with and continually evolving and it's right in the heart of that so. Yeah, it is really interesting conversations to have and there's a lot there. It's very cool. In fact, a lot I think I would say 60% of my the GSOC proposal is just proposing different ideas for designing this event sync because that more than the event source because event source sort of sounds pretty straightforward except you know, trying for transient failures but talking about Jenkins as a sync there's just so much that we need to keep in mind. Well, you know, we have the event parsing the metadata or the body parsing and then creating filters and creating a whole architecture. So, yeah, actually looking forward to the whole Jenkins as a sync and everything related to it. And in terms of those questions around Jenkins as a sync and broader architectural considerations. Are you having enough, I guess support input like I know you're meeting with above a couple times a week. Are you are you. Is there anything more that you need are you going to different are you going to the event saying are you meeting with other people like I think, I think these questions are really interesting we can certainly try and broaden the net of input you have. Does that make sense. I have not really been able to connect with like the right people who would have a lot of sort of idea on this regarding the event architecture. I do think that the event sync is the most relevant for these type of questions and I'm hoping that it will be my first time today, going to the meeting and hearing from them, but I hope that that can be a place where I can raise questions and also have a communication. And yes, they have like talking with you guys and it is, it sort of gives an idea to be sort of steered in the right direction of researching because right now it's just like looking at a bunch of different things. So, I, yes and no yes, because you know they're like all of the numbers in the community are very helpful and they're also like guiding for for this particular sort of architecture. You know, because I get do not really have like being able to connect with, or like I did not actually as these questions a lot before is just starting to come around for Jenkins as a sink. So, I'm hoping once everyone is on the call and also through the same event, so our events like meetups or meetings can get answers to it and have communications about it. Yeah, I think so and the event is a good place to start and Mauricio is, I believe in his new, his new job, he's working on K native. So, I'm like, hmm, we might, I mean I realize he's new he's settling in and that's always such a, you know, there's so much to do that but I think between kind of pulling on more connections that we all might have and then also the event saying I think that will we could get, you know, you speaking to more people, and it would be interesting for you. Yeah, now I want to go to the event take two. So many other things to do but I'm like, I don't want to go. Yeah. Yeah, well, those were the only top questions I have burning questions. I'm pretty sort of set the first thing obviously is this doing or moving the UI from mobile config to having its own page and so I think this week is going to be doing that and also just researching different methodologies of implementing things but but in a more async communication kind of things I have been looking at a lot of them and they all have such different architecture, I get so confused. But, but there's should be on them basically like writing down the all different architectures and what can work and what cannot. So hopefully it should be good for this week and I am meeting with the ball later and maybe I might able to schedule something with Marisha and talk more about these things. But that was that was it for me today. Okay, sounds good. And since you have more meetings in the week we can give you the next half an hour back here. I'll stop our recording.