 How's it going? I'm not sure I'm going to find through the my windows. The. Meeting notes notes up here somewhere. They paste the link in there. We're seeing the meeting notes. Yeah, I am. Not some corporate secret website. Are you going to be on the call this Thursday? I anticipate being on it. Yeah, cool. Because I'm technically at a face to face meeting most of the week. I am hoping to step out for that phone call. In case I can't, I may ask you to go ahead and moderate it. Okay. I'll make sure I leave my, the meeting before we're ready to set up. Good comments coming up pretty quick. Yeah, I think it's going to really sneak up on us. You need to figure out what, what to finish off on the zero point one. You know, I saw the camel case. Change. Maybe finalize HP Jason format. Yeah, there's a couple of other ones that would be nice to polish off. Yeah, but on the positive side, it's all kind of smaller things to me. Which is nice as opposed to really big controversial things. That's good. Hello. Hello. How's it going? It's so weird when you're sharing just that one window, but we can still see your mouse moving around and you clicking on things that we can't see. Kind of freaky. What was that? Well, I believe you're always sharing one window, right? Yeah. Well, we can still see your mouse as it goes over the window. And so if there are other things on top of that window, you can see the mouse moving and clicking on stuff, but it doesn't align with what's being shown to us. So it's kind of weird. Oh, that's funny. Yeah, it's neat. So I'll just give another minute. And now there's a couple of people that said yes to this time. They're drawn yet. I can hear a spell a while away. All right. Why don't we get started? So the intent of this meeting is to talk about interoperability of different projects using cloud events. And, you know, maybe it's a little bit early, but I think as we're finalizing the spec, it makes sense for us to start thinking about how would we see projects actually incorporate cloud events, be able to prove that we can move these cloud events between these projects, either as producers, middleware or consumers. And I'd like to open it up to, you know, the call and have a start brainstorming on what do we think would be a compelling demo of cloud events with respect to showing this interoperability? Anyone? No one? Well, let me start, even though I already talked way too much in this forum. So I can tell you what we have in mind from the Microsoft side, and how we think about integrating this so that we can figure out what the demo might look like. So our product that we'll use this is Event Grid. And Event Grid is effectively an eventing fabric that sits underneath the Azure platform, and more and more services are going to are raising their events out. So if you are adding something to a storage account or a blob, then that storage account is raising an event about that blob being created, and then you can go and react to it. So, and we're combining that in our world with Azure Functions. So that's our equivalent of LANDAS. And also with Azure Logic Apps, which is a, there's an AWS thing for that as well. It's a workflow. It's kind of a workflow serverless workflow engine. Is that the same as step functions with AWS? Yeah, exactly. Yeah, that's the name. I always have a hard time remembering what the AWS things are called. And the other thing is, and then we can also integrate that event flow with our event hubs. So that's the kind of a Kafka equivalent roughly so that you can go and archive events and you can go and do, you can process events later. And we also integrate them with queues. So that's kind of our internal flow that we use. And obviously we want to go and open that up to everybody else. So the events that are being emitted today from Azure are already subject to a set of constraints that we set. So it's not completely Wild West, how teams can express their events that follow through Event Grid. And what we're planning to do is do a mapping of that canonical format that we have to cloud events and then just make it possible for us to go and push towards cloud event consumers and also receive from cloud events producers. So potentially I could tell you that I want to subscribe to a cloud events format? Yeah, so I think that's how it's going to turn out is that you want, if you want to have a notification from a storage blob, from a storage blob account about new blobs being created, then you will be able to wish for a cloud events format and then we'll push that to you. What kind of timeframe are you looking at for having that capability in prototype stage? We can make a mock-up of how that will look fairly quickly. We can do that within a week or two. Obviously product integration is something that will take a little bit more time also because of where we are in terms of stability. But we can make something that looks very much like what it will look like within a very short time because we have a pretty clear notion what that should look like. So effectively we can make a demo with a little bit of hand-waving. And then as I've mentioned in the past, we have an open-source project called Dispatch, which flares above open-faz and RIF. You can have your choice of fazes underneath. We're using cloud events as a common substrate within our event bus. In fact, yesterday I was doing some updates to it based off of, it was originally implemented maybe a month or so back where we had a different spec and I updated it to the latest spec. Which means you take an event in on one side, then you push it out in different rendering on the other side? For the most part, we will convert existing events into cloud events and then use that as the common format within our eventing. Do you have the vendor stuff already integrated into that? Not yet. We are working to integrate external events to be able to pull in different clouds. Right now we do have different event sources, one of which is vSphere. So what kind of events does vSphere emit? Things like create, delete, VM, different lifecycle management events that are occurring based off of the platform. We have flexibility to be able to create additional event drivers. It should be easy to do if there is an external event source that we can hook into, to be able to consume cloud events directly. Could you emit cloud events too? Yes. Right now the main use of it is to send the cloud event into function. So being able to use RIF or open FAS as a function fabric. I'll chime in. We have an analogous use case, an analogous situation where we have event sources and Google Cloud functions and can also do analogous prototyping. Obviously it wouldn't go into production when the specs influx, but creating a bridge that can go between the things. I think it's the demo that I've been itching to create. What about the other folks on the call? What kinds of things do you have? Hey guys, this is Chad. At Oracle we've got a couple layers to this. One would be our event service. There's nobody on the call at the moment representing the event service, but they're integrating cloud events into there so that they can both receive and emit cloud events and transform into a cloud events format. That service will be receiving events from a lot of different Oracle applications and FAS offerings. I need to check with them exactly what we're going to be announcing around CNCF, CUBECon timeframe, but the stuff that we're working on in the FN project site is supporting cloud events natively as an event type for FN project, which is open source. Wait, what was that last thing you said? I'm sorry, I was typing. Oh yeah, no worries. That's the FN project. Oh, right. That's currently open source. That's open source, yes. And we'll be announcing support for cloud events at the event inside of FN. Doug, that actually begs the question as to, that might be on the agenda item for this week is, what kind of PR do we want around CUBECon? Right. So I think I'd like to see what we can actually do. And then I think that's a natural question that we should spin up. Yeah, I don't know. I don't know that the PR question is something that we need to worry about in this call. Yeah, I mean, I think Austin has been working on the, and somebody I've gotten his name working on the website very much in anticipation that like we want to have a nicer presence on the internet. That I think that like we want the, what we've talked about is that the repo and the website would be like welcoming to people. Whereas right now it's getting there, but it's not quite there. So Chad, sorry, I think I might have cut you off. Do you want to continue? No, I think that's it for us for now. Yeah, this is Louis. From Huawei, we have a tool that can run on your laptop, or sort of a tool where you can actually be a consumer of events and evaluate various functions, essentially cloud functions or Lambda functions, whatever you want to call them. Is that a development tool or is that like for desktop apps? This is really a development tool. So it's really sort of called the sandbox for evaluating various cloud functions. And that supports cloud functions from different providers. We can add that functionality. So, you know, once the cloud event is earned up, we can easily add the ability to consume those events. Is that open source? Not currently, no. Is there anybody we've missed from the call? Klaus? Yeah. So personally, I'm involved in Qplus. And then Qplus is also starting to support cloud events. I have to check with the Qplus developers what exactly would be possible. And just so that I have it for the notes and I've looked at Qplus, but I'm not sure I could say it as accurately as you. What are the like sort of, what are the key attributes of Qplus as a fast in terms of what it supports for either emitting or consuming events? Well, I think it's mostly about consuming. It comes with support for Kafka and HTTP. There was a note on the serverless working group, I think, about like supporting Kubernetes events natively. I didn't have a chance to look at the code, but I saw the announcement. Really? So I noticed there's a related project that was emitting events from Kubernetes, but I think that's not directly part of Qplus. Okay. I'll have to look up on it, but thanks. I think they call it Qwatch or something, but I would have to check with the others. Yeah, this is Doug. I'm still checking on the IBM side. Obviously, since we use open whisk, I'm trying to see what kind of integration we can do there. I'm assuming it's more on the consumption side than producing side, but I'm still doing some investigation. How much you guys know. And Sarah, to your comment about Kubernetes events, it is something that we've talked about the adding into dispatch, but I don't believe it's scheduled to be implemented yet. Trying to find, find if I have any reference to that. So much happening. It's hard to keep up with it all. All right. So it looks like we have, you know, everyone is doing some initial work around cloud events. I do wonder how we can, how we would be able to stitch all of these together or show interoperability between the various services. So we're working on some like sort of Kubernetes based Istio based kind of control plane stuff. I don't know if, I mean, Qubeless is obviously Kubernetes Istio based. I don't know if anybody else is. Now dispatch is on top of Kubernetes. Go ahead. I think for a demo, one thing we should probably think about is a kind of, if then scenario where we, that is easy for us, all of us to do. And to realize like, you know, there's some, something that happens and have an implementation of that. And then there's a routing, routing of some sort from peer to peer to a middleware involved to get that to the receiver. And then the receiver does something, but and that implemented in a very high variety of different infrastructures and then go and play, play and play them basically to make it one's very simple generic scenario where the focus is on the interop and not necessarily on the scenario per se. The scenario can be fairly straightforward. It's very, very simple basically because we want to show that it works from everywhere to everywhere. That's something I would prefer instead of doing. It's something that is, you know, more aligned with a pragmatic or practical solution. Yeah. When we were first talking about interrupt demo, I was kind of thinking because we had like kind of set aside the whole like how these things get set up that we could just have a like a one event sort, like magic happens for how these things are connected and an event source, an event source emits an event, right? That then triggers functions on different destinations, right? So you could have like, so like we could construct it so that we have a like cloud firestore project or Google cloud storage project that emits an event, right? That goes through our little prototype. And then that with some kind of hokey registration system that we do behind the scenes, or maybe we put in a file. So it's clear that we can, other people can add to it. You know, we just, or GitHub just like some kind of like placeholder connector thing, registration. And then, and then we can show how that is consumed at different places. Is that the kind of thing you're thinking of? Yeah, I was thinking more to go and normalize on the event. Yeah, exactly. Rather than, so basically everybody builds, everybody builds the same scenario where the event ultimately, a set of events, not one, but a set of events are representing effectively the same thing. So I'll give you the example of inserting something into creating a new blog or creating, let's make it super abstract, create a new object. The create new object, if we make a create new object and delete object gesture, that's something that is generic enough so that everybody can go and interpret that in a way and it makes sense for some emitting system. For the demo, we can keep it very abstract. And then we can have emitters from different contexts which go and emit that sort of event. And then we have handlers on the other side that handle that event. And really the constant piece that sits in the middle between is the event per se. So we've been normalizing effectively on that event as the interrupt anchor. So we would all be demoing like we're using the same format and theory there's interrupt. I mean, I think the most compelling demo would be like one provider emits an event and somebody else consumes it, right? Yeah, I'd be happy if we had end providers and end consumers and we could go and just make them all plug together. But for that we need to have a... All the emitters obviously need to be different implementations of the same thing and that's why I'm enforcing something that's very simple and canonical. Is there a fairly generic like pub subsystem that can sit in the middle that everybody can hook into? Well, I think the key thing is that we're... Like, certainly Google has followed the sort of this model of being able to subscribe to a very granular event. And so the idea that we would just create a fire hose event to a topic is not ideal for demonstrating the power of this venting system from our perspective. And so we don't want to normalize on something that we think is... It doesn't take advantage of some of the opportunities of this format. I'd also say that it might make sense to have something that's more tangible for end users to understand what is this object and why does it matter to me? Yeah, I mean, sort of one of the classic examples is either somebody puts something in a data store and it kicks off some kind of business analysis, data analysis, or the classic, I'm gonna put an image on some kind of... We all have... The folks in the room have cloud storage things, right? And then, you know, and then that does something with it. Some nails. Some nails, yeah. Compnailing is our canonical example for event grid and storage. So that's the... It seems to be a classic, but no. Exactly. I just wish there was a better demo than that. I'm getting tired of that one. Yeah, I mean, we have a demo which is like... It kicks off like a safety filter, right? You can go and insert a customer, a new lead into a sales database, and then send and spam right away. Sorry. Well, I guess we could have an image put someplace and then watermark it with cloud events. Oh, I like that. That's cute. That's actually the... Then we can share it on social media. I love that idea. So then we have... That was the other one. So you could have the user signs up for web, like for app, ad lead in CRM. I like to know... That sort of general database event to app. I'm impressed with your use of special characters there. I knew the Google Docs tricks before I worked here. So Louis, Klaus, Chad, comments, thoughts on ideas? I like the watermark idea. I mean, we could show how anything can emit an event based off the various cloud storage solutions that we have. And then any of the consumers on the other end, each have their own set of functions or workers or whatever you want to call them. But they receive the event because they know what that event type looks like. So any publisher can publish onto some media area. And then any of the consumers can see many of those messages because they know exactly what the format looks like. And they all end up pushing into some Twitter account or something with the watermark dimension. I mean, it is sort of the quintessential example of a serverless today, an event-driven app. It's hard to get away from it. Yeah, we could all put our logo on the watermark. Yeah. Yeah, that's true too. I'm glad I went slow. That would be very genuine. But I'd like to also have the, I mean, I do think it's simpler to just have an example of an event that where like for a first pass, getting an event where all of the data is in the event and you can operate on text might be easier for people to like understand the concept. Because the code is much simpler. It doesn't depend on other libraries. And it would also be inclusive of the folks who don't have storage offerings. It's just an idea. And it might pull in some of the like, I write this to database, like so, Adelaide, and you know, like post to Slack. Like in my dreams, right? This would inspire the like the slacks and the CRM is to be like, oh, wow, we should consume cloud events. That's why I'm always using like, I used to insert new sales lead thing as a, as an example, because that actually picks up a bunch of the, it's something that lots of people can relate to when they're building business apps. And then I basically say, hey, and you react to this by crediting extension application and that's something that seems to be resonating. I'm not saying we should use that exact thing, but using something that's a very canonical database record that people can relate to would be very useful. Because I think for all the cases where the events are not, or sorry, very many cases where the events are not necessarily about motions of infrastructure, like insert something into a blog. Lots of those will be about state changes and databases. So, so do you, I think that, that really resonates. Does anybody have any other specifics on the scenarios or should we talk about like, what are the next steps to get us from here to there? So I just posted a link up to it's an example from dispatch where we did a buzzword bingo slack bot. In the chat? Yeah. Yeah, I see. So since you're talking about Slack, this was one example that we came up with that if you put in the right number of buzzwords and posting on the Slack, it'll come back with bingo. This is just just one more file and I might be able to get events submitted from something like NetSuite or PeopleSaf into some cloud events format, which is, you know, pretty big enterprise apps and then anybody could process, for example, a new record or a change record or something. So I need to go in and explore that a little more. I have to jump into another call right now, but you know, kind of send for whatever we end up deciding on for this. And I've got a couple of people helping out with the words. Yeah, I think that'd be very exciting to actually have a real, like a higher level app that also showed examples of these events. Okay, I'll follow up on that. Super. All right, other ideas? Should we move on to next steps? We're looking over some of our other demos. You know, we kind of, we have a blog demo as well. So if you look in the examples, there's some additional ones. So practically speaking, for the blog demo, that's going to be very simple for us to go and hook up as a prototype because we can go and push to a function and the function basically does a transformation and then pushes to whatever you want it in as a cloud event. So that's going to be very practically easy within the existing production system. So that part is going to be simple. And then we have to go and figure out whether for the other one, whether our CRM people want to go and play with that. If we chose the CRM. You mean our Microsoft has a CRM? Sorry. Yeah, we have dynamics 365 CRM. I should put this up with Microsoft. So I think the next step would be to define like proposed specific events, right? I mean, this was part of our point one milestone anyhow, right? Because I think there'll be, I think our cloud storage events don't actually put the, like we don't encode the actual image in the event. And I think that that is desirable because you might not want to act on the whole image. And that's like a potentially a lot of data. You should have, you should have a link in that. So yeah, there's a reference. Yeah. But like, so I expect that there'll be some things to put out in that, that detail, which I think would be healthy for the application. So, so we have the sort of. Yeah, I think I'd say that if it were a link, then we would need to worry about credentials. Access for that. Although I think that from a specification standpoint, I think that we would want to make sure that we allowed for. Like I wouldn't want to set everybody's expectation that images have to be public to use cloud events. Yeah, I want to make sure that we wrote down, this is how you would do it with access stuff. And for our demo, we're not doing that. Right. Um, so. I think it's actually good to make a point of that, that, you know, when sending a cloud event and you're referencing a resource in that cloud event, the receiving that cloud event doesn't give you access to that resource necessarily. It just says something changed. And if you want to get the details, then you still need to have a way around it to go and access it. I don't think that necessarily. There's that implication that you always, you know, if you're, if you're allowed to receive the event that you're also allowed to receive all access to the resource. Yeah, I think that that's an important point to make clear that will actually make people more excited about using cloud events. You know, another facet of this is multiple language support. Being able to use C sharp. Python, et cetera. Go. Yeah, I think that would be great to have a demo. Well, we will definitely do everything in C sharp. There was a reason I mentioned that one. No, but you would actually be surprised how multilingual we are inside. But I think for the, for the audience, I think you're the natural career off the sharp. Yeah. Yeah. So this simulator that we have can support a number of different languages in terms of the, the functions that we can evaluate. Right. So, um, for the create object and delete object, that's a database object. We have lots of different kinds of who has data store. Like, so we have like fire store, which is like a no single database. Um, uh, who else has a data store that could turn into a cloud event. I know that many of it doesn't support cloud event natively, but they do support, uh, advancing. What was the first thing you said, Anita? No, Minio. Minio. Yeah. So from an architecture perspective from the, like from the CRM system that I was talking about. Um, I was not thinking about that being a database raised event, but it's effectively when that is logically created inside the CRM app, raises that as an event. So it's not, it's not a trigger, but rather a something that the CRM app does as a, um, you know, I just created a new object inside of it. And in addition to storing it, I'm also going to go and raise the event about it. Yeah. And what I was kind of thinking we could potentially do with fire stores, it's a general database, but people often use it to keep their like lists of users. So you could imagine that it's user create event. Like that you, it's a, we could have an example of like, look, we receive a general database event and raise a application. Level event. Right. So it's would sort of show the code of how someone did that. Like, you know, like for, like a lot of our customers are, are themselves creating things like CRMs and whatnot. That have users. I mean, that's, I think at that point it's an implementation detail, but the, I think, um, and if you want to go and delegate that raising up that event through your database, I think that's certainly fine. Right. I'm just trying to think of the, um, interoff example there. I think that that would be like, then we would have a receiver, right? So then we would sort of have a receiver. And you could imagine that I'm now contriving a scenario in my head. Yeah. That like when a customer is created, it's some, you know, some system post is just black and some other system does something else with it. Yeah. Exactly. So I mean, literally this, the, the, the send spam was a semi-serious. Um, you often have, uh, these, um, situations where you sign up to something and then, um, the, um, that company has a house in house fair the next week. And so you get an invite right away for, to that in-house fair and just because the company just got to know you. And so that's a tactical extension that you can very nicely do with an event driven thing. Yeah. So another thought is to, to kind of a trace route by taking, consuming an event, adding a designation onto, into the data, just text, you know, text wise thing received by, and then forwarding it onto another service. And if there's multiple services, you know, you could put in a randomization of who I send it. Does dispatch send it to Google or does it send it to Microsoft and then Microsoft decides to send it back to dispatch or Google, et cetera. Mm-hmm. You mean just bounces, just bounces around so you can demonstrate that it actually went through, um, that many systems? Yeah. Yeah. But it was accepted and it was consumed. And then the new event was produced. Ah. And, and so when you think, think about interop, you should be able to accept it from anywhere and deliver it to someplace else. Yes. And have it consumable. Yeah, that's true. If the, if the relationships, if the relationships for the routes effectively are set up, I agree with you. Yeah. I think the routing where, um, I don't know if we're there yet to have consistent routing across multiple providers. Yeah. The routing is. So one of the things that is in the, um, that we need to agree on, I think for practical interop, I did already a bunch of the work if you might have seen from the PR, um, on H, on HDP mapping. Um, but there's a few things that we need to go and figure out, um, um, to make the HDP interop work. And I wrote that in the, in the email, um, I think Friday, um, that I sent to group because we need to have a, um, there's a few practical things like needing to register a target with the publisher for data protection and security. Um, that's commented like AWS does that for, um, SNS and we do that for Event Grid. Um, there is the question of where do you place a token? And if you look at around the world and what people do for webhooks, there's 500 different ways of doing that. Um, so there's, there's a few practical things we need to go and arrive on and, um, uh, in terms of interop. So there will be a few for a demo that we want to show within a very short time. There's going to be a bunch of warts, um, and we'll probably have to go live with those warts, but just put them on the table what they, those might be because I think one of the things that we can do as a, as a, as an, as a side effect of this interop work is actually go and define a profile for what a webhook really is and then, uh, publish that. And I think that's even orthogonal to what we do. Well, it's, it's related, but it's not necessarily only for cloud events. Um, that we say, Hey, you do an HP post and the HP post is done with authorization in the following way. And, um, for DDoS protection, you need to have a registration gesture. Yeah, I think that, um, I would just want to pause you there, Clemens, because I think that we've basically, until we get, um, we agreed like a long time ago that this, how we set up the connections is outside the scope of the spec. And I think we'll make a lot of progress, particularly the things that can be open in, in sharing what we're all doing to set up these things. And that'll move the conversation forward, but I agree, like in the next few weeks, deciding on all those things is, I don't think practical. Yeah, it's not, it's not going to work. So basically when, when, for all the, the delivery, the details of the delivery, the delivery, like the, the true like specificities, the security pieces, um, there will be some, um, um, special accommodations effectively for every, certainly for every target and, and mostly for every middleware that's there. And then we have to go and figure out over the fullness of time as people say how to, how to even those out. Yeah. So like, I think we should say assume for the purpose of this demo set up is not, it's like behind the scenes, non-standard, you know, like, you know, might, you know, so individual group, like, you know, it's sort of individual, individual projects might demo that, but not core part of interop, right? So we want to focus on events generated and consumed in the same format. Kind of that helps in some way. Okay. So let me put this up here. Um, so then. Does somebody want to volunteer to create these, a draft of these storage events, create and delete? We already have some, but we've got to take, like, you know, we had to start with either the Google Cloud Storage one or the, um, Microsoft one and just turn it into something that matches the cloud events back. I mean, we have those events. It's just that I have my hands full with some of the other things already. Yeah. I don't know what I can do this week, but I could definitely brush up. Yeah. Yeah. I mean, if you take a look around what, what other, what the plastic platforms are emitting, I think they're all fairly similar. Yeah. I mean, we have examples in the repo. Yeah. Although I don't know if I've, I've, I've looked at the Amazon quite a bit, but not the Microsoft one. Clemens, do you see if you just add to the repo or send me the, um, an example of Microsoft? I can't, yeah, I can send you, uh, we have a, we have a doc page where that's, um, we can paste it. Thanks for digging it up for me. Oops. So do we see each consumer subscribing to each producer individually or having a central infrastructure thing in place? I think that's part of, I think that's part of this common, the, the, the, this is conflict, conflict dependent because all of those things will be different. Um, I think that's part of the, the, we're going to go and combine things, um, but, and we're going to make sure that the flow is compliance, but I don't think the subscription gesture per se, something we can be prescriptive about. And I'm kind of, everybody will want to show their own thing, right? Well, I don't, I'm not saying you'd be necessarily prescriptive as much as I'm just worrying about, okay, I want to write, let's say I want to write a, a consumer. How many different types of ways do I need to connect up to consumers? I mean, to, to producers is what I'm trying to worry about in the timeframe. Well, I think that what we'll each have to do is figure out what other consumer or producer is easier. Like I think that at minimum, we will have sort of like sort of, uh, plan, uh, so this is demo assumptions. So I think that what Clemens proposed, I think is a great minimum bar. So minimum, same format, um, used within a cloud provider, and allows, um, who was it that had the desktop tool? Hawaii? That was Hawaii. Yes, we got the desktop tool. So we'll be able to support that common format. Right. That allows to support local evaluation of functions from multiple providers. Yeah. Just that can consume those as well. Yeah, we can have multiple consumers for certain. Well, I think it's the, how do you hook up the consumer to the emitter is the question. Yeah. I think, and I think that's, that's going to be difficult to say, we're going to do it this way because the work is not that far yet. Right. So I think that first, like, let's, let's see who gets there first with like different, like, I think we've all got to like sort of figure out what this stuff looks like. And then, um, and then we can see whether we can, I think we, we should have like, if we get that far, we should get pairs of people to hook up with each other. And something we could consider is that if we, if we get some traction around having our different things work, then we could have like, maybe we could have an evening hack day or something like, you know, for those of us who are going to be at KubeCon in person, we could have a like, let's all make some cloud events. And then maybe we could get other people who are there to work on adding cloud events to their systems. So just, just out of curiosity, is it, is it not worthwhile at all to try to produce sort of an event hub that subscribes to all the producers and then each subscriber can subscribe just to that one event hub and get all the events for all the producers? I think the challenge is, is that we have not aligned on what it means to have to register trigger and what exactly that is. And so while that's interesting, I think that it may be ambitious for three weeks from now. So I think that, you know, I mean Austin's not here and I know that he's very much interested, like they have their gateway. So I think we need to sort of hear from the people who would do those things, how they envision it. And I think that if we move forward and we have, these are the specific events we're going to interrupt with. And there's still some detail to work out about, I'm sure. Right. We'll be like, Oh, no, that's not what I imagined it to be. Yeah. Yeah. So I think when we get into the exact format, that that will then illustrate what exactly the interrupt is. And then. Yeah, I agree. So when I wrote down for the HDP binding piece, I think that might be a good baseline to start from, but then there are still, and I'm actually, I'm intentionally staying away from some particulars, like I'm not prescribing which HDP methods you should be using. I think that people might be saying, yeah, for, well, for this thing you should use a put and for this, you should be opposed. And I also want to have this work for soliciting events from, from a different place. And so I just made it a mapping into the HDP message. And then, and then I think for a prototype, as far as you can go is you could say, I'm going to push those events with that HDP message format effectively. I'm using HDP post and I'm going to react to HDP posts on my HDP gateway for the functions. But then there's, but then still there's going to be a bunch of things which are unresolved in terms of, you know, what is the, what is the purpose that I need to go and get at this thing or do I need to have an HGIP and how does all those things work? We're not going to get to that. We're not going to get to that. And so I think that will end up being something that for each pair of publisher and consumer, and I include middleware in the middle, in the middle into that because that's being a, you know, a consumer on behalf of in that case. I think that will be custom. So I have to duck out. I'm sorry. I have to run to my next meeting, but I'll take with this action item. Thanks for pasting that in Clemens. And then I'll catch up on the notes with whatever the rest of you. So what, so one last thing is I'll also get my team to document how to bring dispatch up on both, uh, uh, AKE, AKS and GKE. And that might also help with, uh, having a independent project running on each of, each of those clouds. Right. Anything else? That was good. That was a good meeting. What, what is the next one? Yeah, I think we might be gated on Sarah doing the storage, create and delete thing. Okay. Unless Clemens, you want to send out your, um, your event grid stuff as, uh, as a proposal for starting point. Um, I have, I think I have a version of that even in the, uh, Yeah, I can, I can, I can try. It's, I'm already spending most of my day on this. So, um, I, yeah, I can, let's, I would say let's give Sarah a day because. I don't want to do overwriting her. Nope. No, that makes sense. I just didn't want to wait a week because I thought that I heard her say, I was, I was, I was a little bit distracted. I thought I heard her say she meant I get to it this week. And I think that might be pushing it out a little. Yeah. If, if, uh, uh, Yeah, let's, let's, let's see. I'll, uh, if, if nothing shows up, then I'm going to do that probably tomorrow. Okay. Cool. Thank you. Great. And, and I think to, to Sarah's point, we need to circle around with Boston, since he couldn't make the meeting. Yeah. See, see what they're doing with respect to their event gateway as well. So if, if, if everybody on the call, if you guys could take a look at my, my HDP PR. Um, and, and also the Jason mapping, I have two of those. Um, that'd be useful because I think that's a, that's a baseline for the HDP. Um, uh, requests. And as I wrote in that email, I think there's a, there's a last bio problem as we just also called out. I'm not sure gonna, how much we can go and resolve that. Um, in terms of auth and DDoS protection and all those things would be nice. If we eventually could. Um, but I'm thinking that's a, um, that's a good step towards that. Um, I also have MQTT and MQP mappings already written. Um, I just don't want to, uh, um, overload people with review stuff. So I'm holding those holding off on those. Um, but I just wrote those MQTT and MQP mappings just to prove that what we're having is, uh, we'll go and map clearly into those. Um, and they sit in my personal repo. Sounds good to me. I'd love to look at those. If you don't mind, uh, Kevin. Go to, go to, uh, Clemens V slash spec in GitHub. Uh-huh. And then you find there's an MQTT transport and an MQP binding of the different name branch. And, uh, you'll find them there. Great. Thank you. The Clemens V slash spec. And then you just look at the branches and then there's one for MQP and one for MQT. Thank you. Welcome. Should we plan on another meeting this week or just wait for the weekly phone call Thursday? I would prefer a working meeting, um, in addition to that, to the weekly meeting. Yeah. One say Friday. I'll be traveling on, um, on Thursday, Friday. So Friday is not going to be possible for me. So Thursday in the morning, I can do it. I could go it, um, before our meeting. I would probably prefer for my travel schedule. It looks like eight to nine Thursday. All right. Tell you what, let me, let me throw out another doodle. Okay. And see how we can converge. I know the Doug is busy on Thursday. Yeah. Obviously don't wait for me though. And it would be nice to have Sarah back on. All right. Okay. I'll send, I'll send that out. And, you know, if not this week, then we could, we might be able to do the same time next week as well. Yeah. Next Monday would be fine. Yeah. And otherwise we still have the email channel. So we should go and try using that. Right. That's, it's, it's a proven medium. We don't have to do everything in synchronously. All right. Thanks all. Okay. Thank you. Bye.