 Hello. So Gabe and Fabio, are you guys new to the group? Hello. Hello. Hi, Fabio speaking. Yes. Is this your first time on the call? Yes, it's my first time. Excellent. So I just pasted a link to the agenda into the chat. If you want, go ahead and add your name to the list of attendees. That way we can keep track of you and know what company you're from and all that good stuff. Sure, I'll do. Thanks a lot. Okay. Gabe, are you on the call? Okay, I guess Gabe stepped away. Hey Doug. How's it going? I didn't realize that was a funny question. Just many threads going off once. Have you done that? Or were you scheduled to do the video recording thing? I did the open source week. Yeah, did you do that already? Yeah, I presented yesterday at 1230 central. Okay. That's cool. Hey, Clemens. Hello, Baram. Baram, are you there? Barely. You're very, very faint, but I got you recorded. Thank you. Gabe, are you online yet? Dan. Which Dan is that? We have more than one in this group, I believe. Mark, are you there? Can you guys actually hear me? I can hear you Doug. There you go. Thank you. Yes, that works. I don't like being ignored. Austin, are you there? I'm here. All right. Cool. Let's see. Chat. I see you. So that's good enough. Let's see. I miss. I've heard before. Mark, are you there? Okay. Let's do Dan Barker. Danny there. Yes. Okay. And to do, do Dan crook or Daniel crook. Yep. All right. Hey, Mark. All right. Thank you. Let's see who else we got. David Lyle. Excellent. How about Alex debris? Yep. I'm here. Excellent. Jim Curtis. Yes. Cool. Thank you. Let's see who else we got. Emily. Yes, I'm here in place of the Ben Hartzhorn from honeycomb. Got it. Thank you. Rupak. I'm sorry. I apologize for butchering that. No, it's fine. I'm here. Okay. Thank you. Yeah. Okay. I know I'm going to butcher this one. Um, You're more volume. Are you there? Yeah, this is beyond here from Oracle. Excellent. Thank you. All right. Rachel Myers. Yeah, I'm here. And as I have Sarah Allen and Thomas. Hello, this is Sarah. Hey, Sarah. Hey, Thomas. I got you. I'm here. I'm here. All right. How about Klaus? Yeah. Excellent. Okay. Gotcha. Oops. Doing some funky stuff. Okay. Dan Rosanova. Can you hear me? Yes. Are you the same Dan that I was talking to earlier about? Yeah, you may be. I think the single Dan banished. It must be you. Okay. Let's see. Is there anybody who has not been registered yet to tenants wise? Oh, wait, there's one. Um, Shrikant. Also your own joint. Okay. You're on. I'm not, you're on a string count. Are you there? Yes. Yep. He got you now. Gabrielle. Are you there? And Kathy. Kathy there. I guess not yet. I think. We're just missing those two. Oh, wait a minute. Stanley. Are you there? Oh, can you hear me? Yes. Which one is that Stanley? Yep. That's Stanley. Excellent. Are you new to the call? Or am I just not remembering you from last time? Nope. I'm new to the call. Oh, what was came to you with? I'm with the VM and Oracle. Oracle. Got it. Okay. Thank you. Shikant. Shikant is also with Oracle. Thank you. You go ahead and add your company affiliation. If you're relatively new to the call that way, we can get that in there. I appreciate that. Okay. Thanks for that. Thanks for that. Thank you. Thanks for that. Actually make place to link to the. Thing again. Okay. I have Gabe through the chats. He said he doesn't have the mic right now, which is fine. Kathy, are you there? Yes. Thank you. All right. Anybody. We're going to start in just a sec here. So is there anybody on the call whose attendance has not been recorded yet? Looking through the list. I think. Oh, Chris. I'm sorry. Who's that? Oh, wait. Nope. You're not at the top. Christina check you there. Too many people typing. All right. We'll go ahead and get started and finishes up later on. All right. Let's jump right into it. Quickly just to touch on one of the outstanding action items. Austin, would you like to talk to the question or issue you have around the website? So we can resolve that relatively quickly. Sure. The Linux foundation has completed the domain transfer. They are now the owners of cloud events.io and.org. However, the DNS information got a bit messed up in the process. So those domains don't currently resolve to anything. And they were previously linked to a Squarespace website. At the same time in the repository, we've been investigating just launching our own website just hosted on GitHub. I'm thinking instead of reaching out to the Linux foundation and asking them to adjust the DNS information. Instead, they should just point it to our GitHub website. And the GitHub website is currently deployed. Thanks to Mr. Dan Barker. He had a great job of getting this up and running. I think we should take a look at it. It doesn't have to be perfect by any means, but I think it's better than nothing right now. And we could quickly iterate on the website to, to refine it. Shortly after we just fix the domain issue. Okay. Is there any questions about that? Where's the website hosted? And are we going to move it to the cloud events or? Yes, we're trying to do that right now. The previous website was just made via Squarespace. Now we've, we're kind of rolling our own. That's going to be hosted on GitHub via, I can't remember what it's called, GitHub pages or something. So we're thinking about just using that. Okay. Sorry, I didn't follow. But I've seen the notes now. Thank you. Okay. We do need to move it to, we need to move it to the cloud events or. Yep. Permissions to do that, but I can need help with that too at some point. So I believe the overall question here for the group is, is everybody okay with using, what is it? Dan Barker. Dan Barker's current version of the website as the starting point going forward. Assuming we'll just make iterations. As you progress. Is that right, Austin? Correct. Okay. Any questions or concerns about that? Cause something better than nothing. I mean, I'm all for like starting somewhere. I just want to point out that we have this consistent almost every week people get confused. Between what we're talking about in events and like just time series data. Some people can fit in figure events, like method, anything async on the internet seems to be an event. And, um, and so, so I think like starting with something, but like making big noise about it. We should figure out how to clarify that in this landing page. I totally agree. I think right now we're just deciding whether or not to adopt GitHub pages to host the website. Um, and then we could, you know, the immediate next conversation is to discuss content. What needs to be on that website. And what doesn't need to be on that website. Right. So I think start, yeah. Let's get started. Start with this content. We'll iterate. Yeah. So Austin, where is the actual source code for website going to be hosted? Are we going to cut a new repo? Yeah. We'll iterate. Yeah. So Austin, where is the actual source code for website going to be hosted? Are we going to cut a new repo within our get repo or someplace else? Oh, I think, I think it should absolutely be within the cloud events, uh, org. Um, you know, however that structure, I don't really have any strong opinions. Okay. That's fine. I just want to make sure I understood the process and that's fine. We'll work offline to set up the appropriate links between GitHub pages and our, and a new repo for us. We should make that an action item right now. Um, if Dan could, yeah, if we, if we agree to make another repository, Dan could transfer or we could just copy over Dan's work. And then we'll just agree to work off that, uh, and focus on content there. Yep. And there's a, just some particulars about how you set it up for GitHub pages that I can, uh, run through once we transfer it over. Okay. So Dan, can I sign you with the action? I need to figure out the appropriate people to talk to to get all that set up. I suspect it might be Christina check. I can help. Okay. Thank you, Chris. All right. So is there any objection then with moving forward with that stated plan of using the current version of the website that Dan has, and then creating the appropriate repos so that GitHub pages can host it. And then we can iterate on that through PRs. Going once. Done. Excellent. Thank you guys. And thank you Dan for getting started on that, uh, website. It's really appreciate it. Definitely. Thank you, Dan. All right. Moving forward. I'm excited. The face to face a coupon. So we took a poll to see who was going to be able to be, uh, in attendance at a face to face. And I believe we have. Seven people who have said yes. Um, I'd like to go. I'd like to suggest that we go forward with the face to face. Whether. We decide it's sort of a, an official meeting in terms of actually resolving PRs and stuff. I think it's still, uh, to be determined. Um, I'm not quite sure how we determine whether we have core or not, but at least like to try to get together. To discuss any issues that are lingering at the time that may benefit from a face to face discussion. So is there any objection with us moving forward with the face to face? Given we have at least seven people who are going to be attending. Uh, The one thing we should discuss real quick is I think we'll be in a good position. Um, if we keep making great progress to really publicize this event at cloud native con Europe, we'll have the website app. Hopefully we'll have like a more solid version of the specification. Um, and if we're able to reach, reach those goals, would it be more valuable to. Or something we should do in addition to the face to face to have some sort of open house, we could sort of connect with people who are just expressing interest, just learning about this for the first time and they want to come and ask us questions and figure out how to get involved. That sounds really good. I'm wondering whether we should incorporate that into this face to face or try to find a time during the, during the day. I'm not sure if they have open house type things that cooped on yet. Something like that. Yeah, they do have something like that. I think it's called birds of a feather. Okay. Tell you what, I will take the action item then to find out if we can get a birds of a feather slash, slash open house kind of thing. Uh, actually, I guess I should ask, is there any objection to me going off and see if we can get a birds of a feather to answer questions from the community? We just have to make sure we have our stuff together before that. Always. That's always true. Okay. This would be, this would be a great time to have something that's already presentable. That would be good. I like putting the pressure on us. Using that meeting to strategize when we go from here, but we should have it here. Yeah. And we'll solidify exactly what here is as we get closer. But yes, I like, I like the idea of having pressure on us to move and get something in place for that. Conference driven development. Exactly. All right. So, um, hold on a minute. So is there any then objection to me going forward trying to get a birds of a feather, set up a coupon and the face to face. This is Rachel. I don't have an objection to the birds of a feather, but I do want to know like what the goal of the face to face is. Like I don't want to exclude people who aren't face to face, but I'm excited to like need more of the groups from like more of the people from this group. So if we could like, if we could iron out what our goals for the face to face would be, that would be great for me. Yes, I agree. And that was, that's what I kind of was alluded to earlier when I said at some point before the face to face, we'll have to decide for example, whether it's an official meeting where we can actually prove PRs or not. Because to be honest, if we only have seven people, I'm not sure that's enough of a quorum to say, yes, we're going to prove PRs. So then we may decide, okay, the agenda is just going to be, let's see if we can hash through some of the open issues at the time to see if we can leverage the face to face time to get better design discussions going. And that may be all it is, it's just increased communication, or another communication channel, but not necessarily an official like PR approving meeting, about the decided to be closer though. Does that make sense, Rachel? Yeah, that does make sense. That makes sense. So basically, we'll get an agenda going before the face to face. Everybody can agree on that beforehand. All right. Any other comments or questions? Doug, I missed the poll regarding the face to face. I don't know where that was, but I didn't see it. I'll definitely be there. And I'm just wondering if other people missed it too. It was in Slack and I just pasted it to Chapman. Okay. Slack. I thought I sent an email too. If I didn't, I apologize. I meant to, but yeah, it's obviously not too late to add your name there. So just go ahead and the link is also in the agenda. Got it. And one of the things I want to raise right now is that if we go, if that cloud native con Europe, we start publicizing this and promoting this effort. I know that there are a lot of large companies who have been collaborating on the specification. And I'm just curious how these large companies would like to characterize their involvement in this effort. Not that we have to figure this out right now. Not that we're asking them to officially endorse this, but if they could give us some, some insight into how we should characterize their involvement, that would be, that would be really helpful before, you know, before we do any type of press push around cloud native con. So yeah, I think that we really have to get to a point where we feel like the specification could actually be useful. I think we, I believe we're going to get there, but I don't believe we're there now. And so until we are at that point, it's really hard to make plans. Makes no sense. I'm trying to figure out the best way to characterize that or the next steps on your suggestion there. I was saying, cause I think it's a good one. Is that just something, well, I don't think get up issues appropriate to track that necessarily. It may be more of a question of. Those are some. Reminding at representatives on the call to sort of put forward some sort of statement or something that state in terms of what they feel comfortable people saying about their involvement. And then we need to sort of gather that someplace and like the Google doc. What kind of thing are you thinking of here? I have a very specific proposal in the contributors list that seems to be like, I've gotten a lot of positive responses. for finding that because I wasn't sure, I mean it just seemed to be lower priority than other things, but that could be, my intent with that was so that instead of just being random people on Slack who may or may not match up with GitHub names, it was sort of helpful to understand what people were doing with the spec, which helps sort of understand people's comments and create like shared understanding of what we're all trying to achieve. And so I pulled that contributors list initially from the doc that Austin had put together and then people added in like, oh, please add me. And so that could be a way that, then people can do PRs if they wanna update how the context for their contributions. So I'm not, okay, so I think there's two different discussions there. There's the discussion of how do we list contributors or authors of the specification? I think that's one discussion. And I thought that's what your PR was more focused on. This second part of the discussion seems to be more about how are people gonna use a spec or how do they want the participation denoted or what do they want said about their participation in the working group? And I don't think that's appropriate to go into the spec itself. It's in the spec repository to give context for people who are, so there's different kinds of contributions to the spec. It's not all wordsmithing, right? All the contributions don't necessarily come in a form of a github pull request, not to mention that some of the contributions came before this repo existed. And so the idea is that people could contribute a statement about their planned usage of the spec, right? As a way of contributing to the effort, right? And that contribution list would acknowledge the body of people who are moving forward with this or participating in it. Can I suggest that we open an issue up to discuss this because I don't wanna necessarily dive too deep on this one right here, but I think Austin, your original proposal about trying to figure out what each company wants to say about the participation is a good one. We just need to figure out the best way to gather that information and then have it someplace available so people won't be making stuff up about other companies. So Austin, I think you have a particular concern about like PR around the event and maybe you could add that to the roadmap because I think that we need to hit a milestone first and then have that conversation. So maybe if it's on the roadmap at an appropriate milestone that might be a good way to address that. Yeah, absolutely. And the roadmap doesn't have any dates on it and this is definitely a date focused thing. But let me take it as an action item. I think you brought up actually a good point, Sarah. I believe that there is a middle ground here for these companies and that is like something in between, there's something less than official endorsement. Like it's kind of more of a casual acknowledgement that they're collaborating on this effort and hopefully their respective companies get some points for being, you know, community focus, good community focus citizens. But I think, you know, when I characterize this in the context of how do we do, how do we describe this within the context of PR around KubeCon or CloudNativeCon? I think this actually just touches on the larger issue that that contributor's list is meant to solve. It's like, how do we characterize these contributors and how can we do this in a way that's kind of informal and not perceived as an official endorsement? I think if we could just solve that problem then we could kind of use that characterization when we go to take this to the press. And that is, hey, these are contributors, they're not officially endorsing this project, we've just agreed to informally kind of collaborate on this and see where it goes. Maybe we could use that to guide our PR efforts, potentially. But I'll figure out how to write this up somewhere and run it by everyone to get their thoughts because I know this is kind of a sensitive subject for a lot of people. Yeah, it's awesome. In the notes, I said, I gave you an actual item but I didn't quite know what to write there. So can you just put into words what you just said into the agenda so that it's documented? Sure thing. Okay, thank you. All right. I have a question about the logistics here for the QCON. Is a paper registration required to attend that meeting? Excellent question. I'll find out. Yeah, at the moment, yes, but we could see what we could do to help with folks that are planning to be there but not attending the event officially. Yeah, because it is after hours so you should be able to sneak in fairly easily. Yeah, but people should have some degree of certainty that they can't sneak in. Well, with Chris on the call, we'll make it happen. If it's after hours, I wouldn't worry about it too much. Yeah, asking someone will help. Asking someone with some powers. So Chris, can you take an action to find out if people need money or to pass to get in? Yep. Okay. We'll do. If it's after hours, I'll tell you right now that it's not a problem. Okay. Okay. Chris will check on that. All right. Any last questions? All right, let's get to some fun stuff. Two PRs that we should be able to go fairly quickly through. First of all, Dan Khan opened a PR just to add an Apache 2 license. Hopefully this is non-controversial. Any questions or concerns about adding a Apache 2 license file to our repo for the spec? One once. Done. All right, cool. Now, last week I took an action item to find some place to play or just to upload documents or presentations that people might give during meetings. And so what I ended up doing was creating a directory called share where people will be able to upload or open PRs to upload presentations, not just for meetings, but just basically, I thought why not open it up to any document that you just may want to share with the group at large, whether it's a presentation you gave someplace else or something else is completely up to you. But so basically the point here is I created a share directory and uploaded the two presentations that were given last week and a short little read me telling people how to do PRs to add new documents to this. Having the document in here has, it gives it no official standard within the working group. It's just a place to share information. Any questions or comments on that? This is Rachel, I think it's great. We should merge this ASAP. All right, thank you. Any other questions or comments? How do you want us to link any sort of like Google Sheets or other like non-binary material? That's a good question. I guess what we could do is do a PR where, oh wait a minute, we don't actually have that in here. Tell you what, but I can do this to me. Well I was gonna say I can create another PR to modify the reading a little to say, not uploadable things, here's a spot to add links or references to places, someplace else that way people can do a PR against the read me to add their stuff. Yeah, maybe if the read me also was an index, the index could contain things outside of the repos. Exactly what I would do. We do that in another repo in CNCF for presentations, so totally plus one to that Sarah. Okay, so tell you what, will it feel okay with me doing that in a follow on PR? That way we can at least get the folder up there quickly. Yeah. Okay, so tell you what, let me just make some notes here. To do. All right, cool. Any objection then to approving this PR? So we can move forward with that. All right, cool. Too easy one's done, thank you guys very much. All right, so back to the presentations or discussions around what is source. Now, on last week's call, we ended with Euron finishing up his presentation, but because he ran out of time, I felt a little bad that we didn't really get a chance to be able to ask any questions in case they had any. So let's just, without Euron going back to his presentation again, let's at least open the floor up and ask, are there any questions or comments for Euron based upon what he presented last week? My comment is that I really enjoyed the design goals that Sarah has contributed. And I do believe as we look at it, every other aspect of this effort, that first we should settle on those design goals and that will really kind of help rain in our focus and kind of get aligned and then look at these, all these other presentations and descriptions of things, just from a similar perspective. Okay, so we do have Sarah's design goals next on the agenda after this source stuff. So we are definitely going to do that. And I don't think we're going to resolve this first. I think I relate to discussion is sort of, what are we really defining? Because are we defining the event or sort of the way to transfer an event which doesn't need to understand the event itself? And I think that leads to the points about source and source ID and event type, et cetera, because some of the examples that contain just as an example, the bucket name and the file name that was sent in the S3 event as a source, I would categorize something like that as specific to a class of events, because there may be another event that doesn't relate to an S3 bucket and a file. So I think the first thing we need to define is what are we trying to define? Is it a way to transfer events or are we trying to define the events themselves? Because I don't think there is enough clarity. I would like to minimize the amount of metadata that we're sort of putting in context and anything that's sort of event specific will be defined in the event schema. Okay, so I'm going to have to ask that we, I might say we shouldn't discuss that. I'm just trying to ask for stay on topic for right now. And I want to get through the discussions around what is source first, then get to Sarah's draft design goals. And then we can have a discussion about what you just talked about, Yaron, is are we talking about just the shape of the event or other things around it like transmitting the event? Because that isn't topic on the agenda and I want to get to that just in a timely fashion. So first focus just on my original question. Are there any questions? I think the issue is that the discussion around source is informed by what we're actually trying to see. I understand. And Sarah, I'm not trying to sidetrack that. It's just we have to have time for everybody to give the presentation on what is source. And so I want to focus on, are there any questions related to Yaron's proposal so that we can move forward and get to Kathy and your proposal or your presentations? This is Rachel. I think that we agree that what we need to do is define what we're trying to define. We all, I think we all agree on that. And so we're with Yaron. Okay. We can wait on that. We're happy to wait on that, but we just want to tell Yaron, yes, we agree. Yeah, I think everybody agrees we need to define what we're defining. I think that's true. Right? Okay. So I'm not hearing anybody necessarily raise any questions for Yaron based upon his presentation. So let's move forward now so we can get through the other two presentations that we have on schedule. So Kathy, do you want to walk through your presentation? Yes. Okay. Do you want to share your screen or do you want me to display the doc? How would you want to? Oh, okay. So let me, let me get permission. Okay. Let me get the permission. Okay. Hold on. Let me quickly do this. I think he know. Hold on. Sorry. How should I do this? If you want, you can just share your screen. That's possible too. I can stop. Oh, okay. Maybe I just share my screen then. Okay. So let me get my presentation out. Just a second. Okay. Okay. So, just a second. So you give me to share the screen. Let me see. If you look at the bottom of the Zoom initiative. Oh, yeah. Yeah. Okay. Let me do it. Hold on. Share a screen. Can you see my screen? Not yet. There we go. Thank you. Okay. Thank you. Let me do a slide show. So if you can try to, try to get through it in about five minutes or so possible. Okay. Yeah. Thank you. Okay. Somehow this, okay. So can you see it now? Yes. Okay. So I think, you know, I just gave an example of, you know, the situation, you know, how we should define the source. So here's an example of the burglary detection example. It's a home monitoring case. Like for example, there will be two events. Like one event is like a sensor detect a motion. And another event is a door or window open event. And this event will go through, you know, for example, the motion event will trigger maybe a picture or video clip to be stored into the cloud storage. And then that will trigger a notification to a service platform, which will trigger a service function to do the burglary analysis. Similarly, you know, the window open event will trigger maybe a cloud messaging system to send another message to the, another event to the service platform, which will also trigger a function. So now we have this. So this analysis will base on the two events. But we can see that the event, you know, originally originated from a home sensor. And then, you know, from a service platform point of view, it looks like it's originated from a cloud storage or the cloud messaging system. And so here is, you know, it could also, the event from the regional originating side, originating source could also travel through some middleware device. So how we should define the event source and source time and source ID and event type. I think currently our specification is not very clear about this. I'm not going to propose just, you know, say what is a source? This is open for discussion, you know, should we put the sort, should we define the source as the sensor from the, you know, for example, in this case at the home or should we define the source as the cloud storage or cloud messaging system, which, you know, interface directly with the service platform? That's my question. I don't know what other people think. I'm thinking, I think in the source should be the, from the service platform point of view should be the cloud storage or the cloud messaging system, not any middleware devices or the source, but the information, the event information itself should have a way to identify the, like, you know, the, how to say it, the original event original, the sensor information, the sensor data there. That's my thought. I don't know what other people think about this. Yeah, I agree that what I was saying before is that if we're starting to go inside into the sensor itself, each sensor will have a different metadata and it will be very ambiguous and it will take us five years to define it. Like, we need to just define sort of what they call the envelope, which is there is the guy reporting the event and here's the schema of what you reported. You want more details, go inside into the event through the schema and we can define potentially a few standard schemas that are not specific to one vendor going for it, but those could be in a different scope. Yeah, but just, just take this as an example, I think there are some other similar, you know, use cases on, but we are going to face the same problem, you know, so what is this event source? We have to have a clear, you know, definition or description of that, you know, spec, so that people can be very clear of the source, means the cloud storage or the cloud messaging system or other, you know, component or other component that interface directly with a serverless platform, which will trigger a function action. Or, you know, you know, the source will be, oh, it's the sensors or whatever the origin and the really, you know, originating side, but from current description of a spec, I think it's not clear, you know, different people can interpret it different way. That's why I think we all have so much discussion. So many discussions, you know, which, you know, people are, you know, kind of like, cannot think up very well. Also, there's a source type, but that depends how we define the event source and then, you know, how we define the source type, right? Source ID and also event type, all these, we have to, I think, you know, when I read our spec, I don't think it's very clear or very, you know, what was that referred to? Or whether there, some people might think there's some duplication here. Yeah, I think that's part of the discussion of what we're trying to sort of clarify. So I think the points you raised, Kathy, are very important that we need to address. Yeah, so I think if we are talking about this event source or source type, whatever from serverless point of view, my take is the event source should be the, like in this example, should be the cloud storage or the cloud messaging system, which, you know, interact directly with the service platform to send the, I mean, to send that trigger event to that service platform. If we go this way, then, you know, the source type, we can define, you know, different source type, right? There's a story source type. There's a messaging source type. There's a video streaming source type. You know, there are like, you know, other source types, right? We can define. But why do we need to define the source types? I think, you know, the different source type we define will have different schema or, I'm not sure. That schema also is not very clearly defined. But what I mean by that is, you know, different source type, the message, the information involved in that event will be different. Right, but that's why we have schema. That's what I'm saying. If we have source identity, source resource, reporting source resource, and we have a schema, then we can, we know where it came from and we know how to decipher the message. So that's why you need the source type, because different source type is going to have different schema. No, but you have a schema name. You have a schema name field in the proposal. Oh, then that's, yeah, that's fine, you know, as long as we, you know, but you can have, you know, so source type outside the schema too, you know. Like for example, you different source type, for example, for storage, the storage is going to have different schema, different fields, or different metadata information, right? For example, it's going to have like maybe column, but if like a vacation. Yeah, schema is a schema. You cannot say, I'm going to define a schema and different people will be able to interpret the schema differently. The schema is a hierarchical, you know, field structure. And I don't think, that's what I'm trying to understand. Why do you care if it was sent through a storage or a streaming? If the event is a IoT sensor, you know, notification, whatever, why do you care? Who was, what is the class of the entity that reported it? So I wanted to just sort of chime in with a clarifying question. I think in this picture, there's three different or potentially four different sources. And it, for me, from my perspective, cloud storage is a very different kind of thing than a messaging system. Whereas a messaging system seems like it's transporting an event from here to there, whereas a storage is like, okay, the sensor generated an image and the storage is saying, oh, am I, did I create that image? Am I like replacing it? Like there may be like storage specific like events that have to do with that object being created in storage, which could be then a different semantic event than the original, like I have a sensor that did a thing. Right, it's not the same like transporting a message from here to there in my view. Right, I agree, Sarah, but I think that in this case, the message queue is a transport and not a source. I'm really interested in Kathy's perspective from her presentation. Yeah, yeah, Sarah, I think you clarified some of my thoughts. Yeah, I think the, if we say the source is cloud storage or cloud messaging system or another system which interact directly with a serverless platform, I think different sources are going to, when they send the event to the serverless platform, that event will have very different information carried in it. And different vendor probably is, different vendors probably will have different ways of organizing those information or those, yeah, I say information associated with that event. And okay, so the different representation, that's another, that's a separate issue. But I think the key issue is different sources, the information carried from those carried in that event, in those events will be different. Yeah, well, particularly the distinction between storage, which I just interpreted to be like image storage, right? Yeah, image or videos. I don't really think of as an event originator because it's just transporting an event. Do you understand the question? So the, okay, yeah, you can say that way, but sometimes some, but it depends, some messaging system, for example, if there's a window open event, right? The from that sensor, the information or the format of that event could be different from the event that's sent from this cloud messaging system because the cloud messaging system has its own, how to say, has its own way of, define of deciding what information to be put into that event and what is the format of that event. It could be different. Right, although most of the messaging systems that I've dug into, you can just put a whole event in it, transport it from one place to another and it's sort of like, it's this kind of opaque thing that gets transported. Can I chime in on something here really interesting? I think we have something interesting here that I'd like to discuss just because the messaging system is actually a good example here because you're right that yeah, it's usually just a transporter thing, but sometimes it does raise events. Like we have a messaging service, it's a lot like Kafka and we let you put a time and window trigger on it where we'll write events to storage rather than you having to read a stream. And so that's funny because it actually ties these two together. So when we write that file to storage, yeah, the storage might raise a storage event, but our messaging system actually raises a special event that is telling you where we've written this file, but it's not an event from the storage, it's from the messaging system. So I think it's trying to bring it back because it's less than the trivial one. So the way to clarify it is saying the source of the event is the sort of the resource that reported the event, okay, because the messaging thing is, just think about email, your game, the two in the email is not your, the email server is the guy that sent the email, which is the most basic messaging system. But if the email system is sending you a notification, then it's becoming the resource that reported an event. Yeah, I think that's correct. I mean, that's what I'm trying to say with ours is our intention on our event for that is you're not thinking about, I mean, you're interested in the storage that was created, but you do wanna know, hey, this actually came from the messaging system. And yes, there's storage information in the data, but that's not really relevant to... Yeah, I think, Varum, you bring up a really interesting point, which is that like, it could be that the storage system isn't emitting events, but that most people who are using your whole system, most of the developers would ignore that would not listen to the storage events, because those are really like under the hood and not relevant to the semantic meaning of the events. And so... And just so you don't blame Brahm, this is Dan, I'm just stealing his microphone right now. The computer's not working. So just trying to watch the clock here a second, because there are two big things I wanna get to on today's call. So Kathy, is there anything really big that you'd like to say? Because we kinda need to wrap this up and let Sarah and Thomas do their pitch. Okay, I think it looks like we agree on the source, the event source will be the system that directly interact with the serverless platform, which send the event to that serverless platform, whether it's a storage or it's a messaging or it's other, you know, that many other system to interact with the serverless platform. I find that... I don't think we can do a conclusion. Is that what we agree on? Discussion of the toss-off, no. Wait, so hold on, hold on. Kathy, the point of this discussion is just to get your point of view across. It's not to necessarily ask the question of, do we agree on X, Y, or Z? That's gonna come later. So we'll wrap that rat hole right now. Yeah, so my point is, you know, I think the source, you know, it should be the component that interact directly with the serverless platform. Okay. Yeah. Okay, cool. Okay. And then we can later define, you know, once we decide on that, we can define source type, source ID, event type to see whether it's needed for that or the need application for that. Right. Hey, Doug, I have one quick question. I just wanted to just, I'll be really quick. So Kathy, what is your opinion of the sensors in terms of what they mean? What is it, that's what, from your perspective, that is not the source site. Is that the event source? Okay. So yeah, that's a good question. I think, you know, so that's what I said, you know, before I mentioned before. So if we define the source as the cloud storage and cloud messaging system, in this example, right? Other example will be other things. But you know, but that event should have some metadata which specify the origin information of the sensor or the, what's that, of the, yeah, the motion sensor or the door open that sensor. So actually I have some other slides which bring up another incident. I don't know whether I should, I can. I know. No, let's say that. Because I, like I said, we can't let this conversation last too long. Thanks, I just want to be clear on that. Thank you. So Kathy, can you stop sharing? And then Sarah or Thomas or someone from your guys and you want to share your screen? So yeah, I'll share. Okay. And just let you know, I've been saying five minutes but obviously we've gone further than that. I know we're not going to go very far. So what I want to do, Sarah, is have you guys try to wrap this part of the discussion up at the, within 10 minutes. So five minutes left only for the sole purpose then of saying, Sarah, you have a PR out there about the design goals and negative way to review it. So because next call we're going to dive deep into that. I would like to be able to have a quick discussion on this call about the design goals. I would too. So if you can get this stuff done sooner. Oh okay, absolutely. I thought you were deferring it to next question. No, no, no, I want to get to it but I wanted, I didn't want to cut you off since Kathy had more than five minutes but if you can get it all in five and then the next 10 minutes for the design, let's do it. So it's all up to you. So can you see my screen? Yes, we can. So yeah, I'll move to presenting. So this is just a kind of a very high level how Google Cloud Functions fits into this world. You have a, in this example, a developer calls the Google API to do what we colloquially call trigger configuration, right? So you say basically say, I'm interested in a Firestore document create message and I want to connect it to my action in this case of Google Cloud Function that will do post-a-slap. So this is the intent is when in the lower row a user which is maybe using a device or there's a server that calls a Google API which is the Cloud Firestore API that would then and writes to a very specific path that would then trigger a Google Cloud Function that gets that notification and that data. So in this example, the source is Cloud Firestore which is a Google service and there are many of these and then the action is Cloud Functions and we think of the event as just describing what happened in Firestore and that data changing and then it gets transmitted to the action. Any questions about that? Nice and quick, I love it. So I just wanted to share my help. Oh, I'm sorry. So the, it's similar to Kathy's, but it looks like you have an originating source coming from maybe a cell phone or some server to the Firestore. So there could be other upstream events that are actually triggering the commit or the document create in Firestore. So yes, however, oh, sorry, I'm sorry. Seems like a similar issue of actually finding some information about the originating source of the transaction or the chain of events. It could be modeled that way. Our proposal is that we can set the, I mean, and in fact our current implementation is that the Google service is the source because what the event that we are transmitting is we have done a database mutation which is different from a user click the button or a user spoke into their phone. That would be a very different event. And so I did prepare like sort of this contrast of the common eventing architecture which is sort of loosely based on your own diagrams where the source goes through some kind of relay gateway to an action. So if we wanted to consider the source being user spoke into their phone then we could treat Firestore as a relay however that's not how we've modeled the event. And given that we're modeling the event as a database mutation that leads us to say the source is the Google service that does that transaction. And so basically I think there's sort of two architectures that we're mostly conversing. One is the sort of IoT case or the case where you've got some remote device where it relays through a number of things to the action. And then we've got this is the other eventing architecture. This is sort of how we've imagined it happening in the open source where I could sort of loosely based on how we've imagined it happening in like something like Istio where the source might be able to then have some logic which says, okay, should I admit an event and where does it go? And then goes to an action. So kind of I think that's... The two diagrams don't really conflict from my perspective because what I refer to as a relay is sort of a transparent relay. Even your message probably goes through some message queue or Lambda asynchronous messages under the hood goes through SQS or something like that. So that relay is essentially not an entity unless it wants to sort of proxy an event. Yeah, so that's really like this transport. Like I see this as very like two details on the same theme just like you say you're... Just didn't understand in your proposal again we listed three things around with the source, the source ID and the source type. And in your diagrams right now there's only a single source identifier. So there is a conceptual single source. I don't think we should dive into this but I noted on one of the comments that of how we might map this and what our original thinking where I think namespace maybe is not the right name given a bunch of the confusion but that as written in the spec source is an object with the properties type and ID which I think it hasn't been clear in some of the people who come in the last few weeks to give really valuable feedback. So I wanted to kind of illustrate this is one way of thinking about it. But I like the idea of having a breakout session where we can dive deep into this and really come up with a proposal about how these attributes work together because talking about them as individual attributes I don't know if it is steering the conversation aspect. Yeah, because if you look at your source ID it's essentially schema specific because it talks about the actual object that was modified. Yeah, so I don't wanna dive into that. I just wanted to illustrate that I am not specifying in this the source attributes. I'm rather identifying the conceptual source and once we agree on that then we can talk about how to identify it by attributes. I think in general, if you look at all the discussions I think we roughly have a consensus about that. The only thing is to try and think put things that are belong to the actual event description like the buckets or the file name in the event itself and trying to minimize the amount of metadata because if we open the door for more metadata everyone will come with a new idea for another sort of metadata. So what I'd like to do is not dive into that discussion because I don't think we have enough clarity to actually turn it into a pull request. I think we're close, but I think we're not there yet. I have a question. If there are objections, minimize the number of fields I think that's the general question. So you're on and everybody let's focus the discussion on questions for Sarah about their point of view limited to that. So I have a specific question and that is so what are you, what's your proposal because I think that wasn't clear to me and also to the other folks that I'm talking to is you're juxtaposing the common event architecture to what you have here. Actually what I'm saying is I believe these are all the same thing, which is that the source defines itself by the events it emits, right? So in this picture, because the event is a database mutation, the source is Firestore. And then the IoT case, right? Like whatever the event is determines its source and you may have, like what's not pictured in this first thing is that the heavy green arrow from source to action actually has a transport in between. So, okay, so follow on question. So you have the phone post a message into, so the phone, something happens on the phone and now you post that into your Firebase. Are you saying that the event that is now causing the action is happening because of Firebase and you're effectively securing the original event? So we have a native mobile app where the user clicks a button and there's like some kind of like graphical user interface event that I'm suggesting is not part of what we're talking about. And then the mobile app makes an API call to Firestore, which is a cloud product. And that API, you could call that an event, but I'm saying for this case, we are not modeling that as an event. That is a choice of the design of this system where modeling the database mutation as the event. And in that case, the originator is Firestore rather than the first mode. Okay, so you're saying that's implementation choice that you're effectively making everything an event that is sourced from the database. I'm saying that the, I could draw a different picture, right, that would be more like this. Yes, and then the relay would be fire. And then I would have a different set of events and we may do that in the fullness of time, but I don't think that we are going to the extent of modeling on click as a cloud event. Okay, so Sarah, I think we're going to call time on this just because I don't want to run out of time for you to do a quick introduction of your design goals. So obviously that we're going to continue discussions about source and stuff. So you want to share your screen for your design goals PR and just quickly introduce that before we run out of time. Sure thing. All right, go for it. So what I've attempted to do is synthesize what I think that we've been talking about with a few, thank you, Clemens and Doug for chiming in on different things, but the idea being that this is not, events are often, what I'm trying to do is disambiguate what we're talking about from, in the industry, people talk about asynchronous messages as events. This is more specific than any messaging system. People also talk about time series data, log events, right? Anything logged, anytime series data, any metric is an event. I think those are other different specific cases of events and what we're talking about has a event which represents a thing that happens as occurrence as discussed in the spec and there is some way of specifying how sources are bound to actions. And so I've framed the goals as creating interoperability so that cloud providers and third-party tools and services can all cooperate so that we have this ecosystem of new event sources, new event consumers and lots of tools and libraries and different things. And so the key properties of systems are this sort of source and action which can be decoupled and then the idea that there is some kind of configuration step that binds the two of these. And I think based on the discussion in the last week, I've pulled that out of something that would be specified but included in here so that we can illustrate that such a thing exists to distinguish from general messaging systems where you're like, I have a message and I know what the destination is and I'm sending it there, which is very different from what we're talking about an event which is a thing happened. All right, without going into deep dive because we don't have time, are there any very, very high level questions for Sarah? Okay. So one of my questions, Sarah, let's assume that the event is sort of submitted into a topic, for example. Would that topic be somewhere in the metadata? Which is because it's sort of a logical endpoint that the event was targeted at. So I'm suggesting that the event and what I think like to this design goal is attempting to communicate that the event does not know anything about how it would get to its destination. So it would not include the topic. However, it should be able to interop in a system where you could have a rule that specifies you need this topic to get to this destination or whatever your system requires to route that event would then be outside of the event and communicated to the source in some way. All right, but would the consumer have a way to know where was it targeted to? So I think that what the other part of this PR and thanks for asking that is the README where I've said that the process, right, that first we're doing the common attributes and then the architectures and then how the events are transported. So my current thinking is that that comes into the how events are transported in the message envelope, but the key thing is, and we may need to address some of these in parallel in order to separate the transport from the event. But I think that the sort of that transport question you could say that the consumer hears about it's how it got there from the transport. Okay, anyway, I'm gonna have to call time because we are at the top of the hour and I know people have to jump over other calls, but next week we're gonna continue both these top hot discussions, source as well as design goals, probably design goals first and then switch back to source. But please take a look at the PRs and be thinking about some of the existing PRs out there for how to redesign the source stuff. But before we adjourn, I wanted to do five. David Baldwin. Yes, here. And Grish. Grish, you still there? Yes, hey, I'm here. And back to Joe Sherman from Microsoft. Okay, thank you guys very much. And I apologize for running over. Can you add me as well, Doug? Louie. I'm sorry, who's that? This is Louie, can you add me too? Yes, Louie, gotcha. I'm sorry. Anybody else on the call who is not on the agenda? All right, thanks guys. Talk to you next week. Thank you. Thank you, bye. Thanks for your great discussion. Yep, bye guys.