 Matt's on his way, so I figure we can wait just one more minute to get him. Sounds good. So if anyone else has agenda items I want to add, I think we have an announcement about Envoy-Clonin matchmaking for Envoy sponsorship. Anyone else have things they want to add to the agenda? Yes, I'd like to talk about IO handles. IO handles? Yes, there's a PR related to this and some discussion on it. Cool, sounds good. Add it on. Actually, Chris, do you want to talk about Envoy-Clonin at all? So you're here. Hi. Yes, sorry, I'm about to, I can only stay on for five minutes, but just a friendly reminder that the Envoy-Clon schedule is posted, sign up and all that jazz. So it's a separate kind of registration from KubeCon, so make sure that you're actually registered for Envoy-Clonin and not just KubeConin. Cool, sounds good. Sorry, did I miss anything? Just added one more thing to the agenda, but do you want to talk to the matchmaking service? Issue one. I didn't add that, but I think I know what the context is maybe. Let me see. I think there was some discussion about how to actually get people paid to work on small issues, and I think that service was raised. I honestly don't, I don't have any experience with that service or know anything about that service. I think Chris actually had some thoughts on that and was not in favor, so I just don't know. I'm not necessarily not, well, not in favor, it's not the right characterization. I just don't think you're going to get a lot of benefit out of it, at least from experiences we had with these kind of bug-bound things. If you have like small issues like dock improvements and stuff like that, you'll get a little bit of traction, but we're happy to experiment. If you have like a few issues that you want to fund, like seeing it's happy to fund an experiment. We just need the Envoy team to like give us a few issues and we're happy to chuck it on. Yeah, I mean, to be honest, I really haven't thought about it much. Like I suppose that we could, I mean, we already have that beginner tag, but I guess we could make a new tag for like, for issues that would be really nice to have for a project growth perspective, but no one's working on. So, I can maybe take a look this week and do a triage for that, but if anyone out there has any, you know, any issues that you think fit that bill that you think would, you know, lead to project growth, but no one's working on. If you could ping the issue, that would be great. Cool. Okay. What else is on here? IO Handles. Okay. I just added the link to the PR. Okay. Did Stephen had asked, Stephen. Stephen. Yeah, thank you. There's, we see Joshua and somebody else. There's not many people here for this discussion that I have a few questions and some discussion based on the comments. And it might be better if at least Joshua were present for that. Should I just. Yeah. Unfortunately, we've got a full on site at Google today. So our entire orgasm is missing. I just ducked out for this. I mean, I, I think probably Alyssa and, and I can likely answer your question. So why don't we, why don't we try to talk about it. And if we, if we feel that we can't, then we can defer. Alyssa, are you familiar with that? Are you just reading over. I'm looking at the last couple of comments on the bottom are the most relevant. Okay. So, Joshua and somebody else mentioned that they were thinking of IO handles as a base class. And I think it's going to have a base class as an interface. Yeah. Yeah. Right. Now, one immediate observation I have with that is, is that. So in the generic sense, if it's really an IO handle, we have all all IO ish type of method hanging off of it. Then it seeds, it seems, first of all, to, does it make the transport socket kind of go away or irrelevant or derive from it. We would use it, I think, I'll say, I don't know if the context helps, but one of the reasons we, and I can speak to this want to move away from an FD abstraction is for quick. Right. Because for quick, just because of kernel implementation, you generally end up with one big listening socket on UDP 443 that handles all the incoming quick connections. So if you want to do a normal FD option, like, you know, setting your buffer sizes or setting cross bits or something, you can't do a set sock opt on it. Right. You have to have an abstraction that encapsulates the FD and the operations you want to do on it, which are implemented by the hood by like the quick connection. Yeah. Yeah. And, and the way that I've been thinking about this, that I think would make it easier if it's a little too abstract and confusing right now is that, like I mentioned in the issue, I think the way to do it in the beginning is to make the IO handle has to have the various methods hanging off of that class and actually have the have the dispatcher spit out IO handles. And then, and then basically everything within the dispatcher will be will be hidden like all of the lib event, all of the FDs. Now, now that that might not be what we what we need eventually right like because we might still need a timer and like there's a bunch of bunch of other stuff but to be honest, I think, I think that's an okay phase one. And I think that should be pretty tractable. So that's, that's where I would, I would suggest that you start is that right now, like address is a static class basically all of the FDs are their own thing. And I think if you think about it where right now just his dispatcher basically abstracts live event so the rest of the code doesn't know anything about live event. I think if you have dispatcher abstract both addresses and FDs. I think it'll fall into place. And I would go further to say that in the beginning, like it may be true that like in some of the rest of the code you have to when you're past an IO handle you might have to dynamic cast that IO handle to like, you know, like a live event dispatcher IO handle or something like that. You know, I think there's, I think there's ways around that but I think like in for a first cut just for discussion. I think if you can get that far. I think that's probably what what we need. Okay, that's okay. I don't know if it'll be helpful but I think some of the system people who started with the VPP work had documented at least some of the interfaces that they knew they needed to cover. Well my understanding is, and I'm new to this that all that work doesn't exist anymore it was tossed away. There's no remnants of it. So it was deemed as not the right direction so that's all I've heard from Ed. I mean, we, we never saw anything. So if, if it was thrown away, it was thrown away by Ed or whoever was working on it. Yeah, it was just trashed. Okay, so. Okay, by the way for VPP, just not that that is necessary for this discussion, but the VPP integration once we get to that actual part will be fairly will be more straightforward than you might think. Because VPP offers a library interface called VCL the VPP communication library and it offers all the API's to talk to VPP as a client and all the operations you're going to do on it. So any, any methods that we end up with are going to wrap those VCL APIs. And we get events as well. So the uses the poll type events. Right. So, I mean, like my, my assumption and, and again, this is probably not correct, but my assumption has always been that for something like VPP or DPDK that like you would end up swapping out the entire dispatcher. And, and I think, and I'm probably simplifying, but like I think if that were done, and then that implementation supported timers and like making making connections and all of the IO operations, I think it would quote unquote just work. So that that that's why I'd like to head in this direction and I think if we make the dispatcher implementation pluggable. I think we are where we need to be that's that's my intuition. And I think we need to do that. And I'm not, it's, it's not clear to me yet. I'm still looking at it that we even need to modify the current dispatcher. But we'll see. Okay. Yeah, anyway, that's, that's down the road. Yeah, I think just for phase one, if we can, if we can just do that first abstraction because as was previously said by Alyssa, we already need this for quick. You know, and I don't know that any of us have thought about it enough to know what the full end state is. But I think what we're describing here, I think it will get us closer to where we need to be. Also, I think this might be useful for the windows port. Yeah, yes, totally totally agree. So like there was that other issue that's coming up and like they have their, you know, their their windows version of their handle and like it would be way simpler if we could have a platform directory with IO handle implementations. Great. Thank you for the clarification. Yeah, but my, my advice is still the same, which is I would say the the sooner that you can get a smaller code that we can help review the the better and my suggestion is still that I think you can do this in such a way where there can be intermediate PRs where we still expose the FD, but we start actually taking an IO handle as a parameter on certain method calls, and we can kind of like flush out if that if that feels right. And then, you know, and then once we agree that we that we're on the right track, then your end goal is just to remove the FD method off of off of everything, and then we've won right but like I don't think we have to get there and one giant PR. Okay. Thank you very much. That's clear. Yeah. Um, does everyone agree with that Alyssa, Greg. Yes, I think we should do this in baby steps. Yeah. Okay, great. Okay, basically non functional changes that are small enough to review and verify that they're pretty likely correct. Okay. Great. Anything else going once going twice. See you guys in two weeks. Bye. Thank you.