 Hey, Clemens. Good morning. How's it going? Hello. Hello. So we currently have the discussion on the Google group. Should we put that in this doc? I think it'd be easier to have it in front of us as a doc so people can comment on it. Or should we pull it into a separate doc so that we have it with the two discussions. So we currently have it in a Google group. I just made a, if you're referring to the user stories, then yeah, I just made a merge request an hour ago. Hello, Sebo. So here's a link to Clemens PR. So maybe I'll share my screen and then I can add comments and then Clemens can integrate them close to the meeting so that they can participate async. I apologize, I wasn't able to. I was out of town traveling for Thursday afternoon last night so I wasn't able to chime in but I did read up on it. So thank you for Clemens for this. Yeah, so what I did is I took the 12 cases that I laid out for easy, that was mostly all for easy consumption and kind of for people kind of self-selecting which halfway worked for a few and then consolidated them into four and then added some further commentary. So now I have applications that produce, applications that consume, middleware that routes and then frameworks that help you dispatch to handlers and just generally provide abstraction. Great, so should we just go through them? Oh, go ahead, Doug. I was just gonna ask, is there any bigger reason you put it into the spec itself? Do you expect this to be normative in some way as opposed to sort of a more like reference material? I didn't know whether we wanted to have that in the spec I thought it would be, didn't we want that in the spec? If we don't, that's fine. I don't even care what document that goes in. Okay, it's not a hang of discussion, I was just wondering what your thought process was but okay, it sounds like it's a pretty discussion. That was, I just was looking for a place and we had, since we had that kind of, we had the requirements in the overall goals in the spec, I just put that right below them. Okay, we can talk about that later then, okay, that's fine. Super, so who do we have here for disciplines? Oh yeah, Austin. Hi Doug, hey Sarah, hey Clemens. And I don't know how to pronounce, Stevo, Stevo? Yeah, Stevo, both fine. Super, so let's do a quick round of introductions. My name's Sarah Allen, I'm from Google and my interest in this is the events that trigger cloud functions. And also I'm in touch with the IoT folks and people around Google who have different purposes for events. My name is Clemens, I represent Microsoft for everything that's messaging and standards. I'm the architect for the messaging team inside of Azure. We have a whole fleet of messaging products and we plan to use cloud events or intend to use cloud events for use with our services. Hi, I'm Austin Collins, I'm a founder and CEO of a startup called Serverless Inc. We make a very popular open source project called the Serverless Framework and we have another project coming out called the Event Gateway, which is a vendor agnostic event router. Let's take this, oh sorry, go ahead Austin, I thought you were done. Oh, we hope to use cloud events for our event gateway. If we can get this to a version that's usable. All right, so Doug Davis, IBM, heading up our open source activities related to cloud native stuff. And I hear also sort of representing all the various, many, many messaging type products within IBM to make sure that what we produce here is something that is consistent that we can then leverage in our stuff here. So I'm just gonna make sure that we're not doing something that we can't support later in the future within IBM. And I'm Steve from SAP, a software engineer building various messaging platforms and the standards are good. We like to apply them to our solutions. They make them possible to connect to the others and extend. Great, so yes, I thought that we could just walk through these four scenarios. And I think that basically we're looking for things that would let us know if we cannot do these things, then we must change this back. And if something is not required, we may defer to a, like we may bucket these things. But in any case, the focus is one of the things that must be supported in order for this to work. So we've had a number of conversations last week and then Clemens pulled together these scenarios. So I think I'd like to just dive straight into the scenarios and then we can kind of worry about the framing after we get some alignment, is that good? Yeah, I'm not sure whether I need to read them out loud because you all are very well capable of that reading. What would be interesting is to find out, like one by one whether, so they try to capture one group of application developers who built this thing. So I'm not talking about the persons, but about the artifact that they produce. But so I'm talking basically from the IA perspective of the application per se. But the first are applications that produce events and basically their perspective. The second is applications that consume events and their perspective specifically also in what they're interested in and what requirements they drive really on the producer. Because the distribution here is that and from a requirements perspective is producers are dictating what goes in the event because they sit on that information, right? Consumers express the interest of what they need in an event and then there's middleware between the two that kind of also has requirements also on the producer for things that are required. And then there's the framework of people who have a few special needs beyond what the middleware would care about. For instance, like how do you do a dispatch into a particular function? And that's how I structured that. So start with the producer, set the context, see what the consumer then wants from that producer, what the middleware in addition wants from that producer and then what the framework might also want from the producer, that's where it comes from. So question is whether I've captured the producer per se well. The fourth paragraph here, the produced events might be rendered directly by the producer or by the intermediary. That's specifically I think interesting for IoT where you have devices that are hooked up to Laura one or to SIGFox or any of those networks. Where they do event events and the events are actually intended to be cloud events if you will, but they can't express them in the cloud and format or anything that we define or there would have to be some very compact mapping because the factual message size you can express is like 12 bytes. And so there will have to be massive trickery and I'm not sure we even want to attempt that. So even though the originator of that event is really doubtlessly that device with its context. So I just want to pause you Clemens because I think you've kept, I think you gave a really good overview and now we're diving into the details. And I think- I just want to explain to you where that paragraph exists. Yeah, I think that- Emerald for two more sentences. And so here's a case where you have a network gateway acting on behalf of a device that is the literal producer of the cloud event but is really not material for the event itself. It's basically just a translator. Great. So first of all, before, like what I'd like to do in this meeting is just to go through each paragraph and make sure it's clear and that we were aligned on what these things mean. But before we do that, first does, so personally I think this structure is very helpful but does anybody have any comments about these sort of four categories and kind of this approach to explaining the scenarios? I like these four categories. I think it covers a lot. These are very broad categories. There's a lot that can go into them but just using these categories as our conceptual framework for approaching a person this conversation I think is great. It's inclusive of pretty much all the most important pieces. Yeah, I like the categories as well. My actual concern wasn't with the categories because I think it does a very good job and keeps it nicely abstracted. My only concern was, I don't necessarily see these as uses scenarios as much as more like a description of producer versus consumer stuff like that. So maybe some wording when I want to do in the intro paragraphs but otherwise I like the categorizations, yes. Stego? I like it too. So especially the first sentence, yeah, that will take all of these perspectives into consideration. I'm not sure that all of them will really be like covered by the spec but at least verify that this can be applied. All right. Yeah, and so I think we'll have to work on the framing paragraphs to explain that the spec isn't going to implement all these things but enable these things. And so that'll take some wordsmithing and we'll get back to that because I think that framing it after we have alignment on what it is is a little easier. Super. So let's just go paragraph by paragraph. The first paragraph applications produce events for consumption by other parties. For instance, providing consumers with insights about engines or activities, state changes or environment observations or for allowing complementing the application's capabilities with event-driven extensions. Is that clear for everybody? Or does anybody have any adjustments before we? I think it's fine for now for my perspective. So then in the next sentence, I wasn't quite sure what a base classification was. Clemens? Yeah, that's the, I'm trying to explain that with the next two sentences. You're basically talking topic. Basically, right? I'm saying there's two, there's either a context. Yeah, I mean, yeah, ultimately it's a topic, right? So you have a context in which a, the context is something that, so I'm using these two terms of both in this write-up. Context is something where you have a, like the device here, where you have a mount position, a room, a floor, and a building. And then specifically about the temperature sensor may goes into a mount position. And if that breaks, another temperature sensor goes into that mount position. But the context of the temperature sensor is its mount position. That's something that's a classification, something that's a little bit more abstract. And that's, I'm representing that by the classification by, for instance, league and team, if you have a sports result. I have, and I have an example for the sports results, actually further down in the framework section. So what about if we just, I think if we just remove the word base, it would help. And then just to add a four example. Yeah, I have, I mean, these are examples, right? Yeah. Just one clarification point. Mount position, by mount position, do you mean, for example, the angle at which a camera is pointed or the fact that it is camera number three out of four? Yeah, I mean, I mean, there is a, there's a, there's a mount in the left, in the left far corner of the room. Right. Temperature sensor goes. And if you, remove that meant temperature sensor, the next one is also going to go in that mount position. That says it's set, it's context, right? That's what I thought you meant. I just want to make sure, because a newbie reading this might interpret mount position as the direction of cameras pointing. That's not what you meant. But that's also context, you know? But it's not a camera. It's a temperature sensor. Right. I mean, it could be direction. I mean, it could be whatever. I mean, maybe we'll just say by position, by physical position. How about? Set again, replace it with. Physical. I don't know if you can see my screen. Physical position. Yes, I like that. Physical position, room, floor. But I'm trying to give you an example where I'm literally talking about the thing that the temperature sensor goes into and not where the temperature sensor is. Oh, I see. By physical. By. It's the mount. Right. Come up with something, another word that. I think it's the word position that might be confusing because position could mean which way you're pointing versus where you're located in the room, right? There are two different ways to interpret position. Okay. Hi. You are now, or you should be able to come with a better word than me. Yeah, is it, can we say mount location? Okay. I mean, nobody could be, I mean, it also could be where it is in the room, right? Well, mount location fits. I just want to make it clear to someone that they're that, so to me, I mean, I'm wrong here, but to me the angle at which the camera is pointing in someone's mind could be a sort of a positional kind of a thing. I don't know where you take the camera from because it's a separate picture. I have a fixture. No, no, I think, I think, I think location was fine. I think mount location solves it. Well, I mean, I think that a location in my mind conveys geolocation and if that's not what something you want it like it could be that the temperature center also knows where it is as it moves around. If it were to be like, you know what I mean? Like, and if that's something you don't want to convey, I don't think it matters. No, these are just examples. Maybe like remove this one particular, make simple. That's a good idea. So, so, okay. And then the producer application might reside on server hosts or on a device of any kind. So that might be any application. I mean, what are you getting at? What are you trying to illustrate there? I'm saying we're not constraining ourselves to server scenarios here, but this could literally run anywhere on the mobile phone. The producer can be anywhere. It can be on a server, but it can also be anywhere on any device. Maybe adding that language in would be helpful. Yeah, producer. How about that? The producer could run anywhere such as on a server or a device. How is that different? It's just, You just like that, though? Emphasizing the anywhere rather than specifying host, like server or device. You know, it's just based on the conversation. Yeah, Clemens, when I first read this. It says the same thing. Okay, great. If you feel it says the same thing, then I think we're good. And then I think this is an important paragraph that Clemens mentioned in the introduction. The produced events might be rendered and emitted directly by the producer or by an intermediary. As example, for the latter, consider event data transmitted by the device and so on. Do we need to be clear that this does not change who the producer is to sort of clarify all of our conversations about source? The producer is still the original producer or? So I, yes, exactly. So the point is the production and the rendering into a cloud events format might be in different places. Yep, I think it's a very important distinction. So I'm gonna add like the rendering event in a, by an intermediary does not change the semantic meaning of the event, specifically that the producer. So what I've added is the rendering of an event by an intermediary does not change the semantic meaning of the event, specifically that the producer remains the same even if the event were not originally produced in the cloud event format. That's good. Okay. Okay, so that's producing events. What are you missing? I think that's, is there anything we're missing from event production? We're, but let's, specifically, if you're missing anything in that section, then we might come back to, we might, you might see that the requirements are being thrown at it more or less in the next sections. Okay, so let's keep going. So on to the consumer applications consume events originating from devices under people under applications, modules, instances for display, archival, analytics, workflow processing, or other handling. There are all kinds of reasons for why you consume events. And from all kinds of different contexts, that's the point of this, right? So you may have apps or the originator, the context you care about really, might be the device or might be a person and might, or might be an application. And if the event comes from a person, the producing application per se, the bits may actually be immaterial. So it's the context that matters. And then you can do 100,000 things with it. And I specifically call out things like archival because that, you know, captures things like storage and all the special cases that people express here, what they do with them. So I wonder whether we should just refer to producing applications because that's what we have up here. The point here, hang on, let me, oh. The point is, so no, this is the perspective, right? This is just, this is a perspective. The app, this is what the app, the consuming app cares about, right? It doesn't care, the producer cares about it's putting stuff on the wire from its context so that others can help it make its context more whole effectively. That's kind of the motivation for why a producer does that. The consumer here doesn't care as much about what the producer does. It just is, and what the producer cares about but it reacts to events that are coming out of them. So it cares about the contexts, about certain contexts that events come from. And whether a producer and what producer puts them on the wire is not so important for the consumer. Between the first two paragraphs, I'm curious if the addition of the word platform tool is meaningful or whether it was just in your head at that moment. Yeah, I see, I've been, yeah. I had this distinction in the original 12 points. I had started doing the structuring, structuring a little differently today and then fell back in making platform tools and applications really just be a paragraph here. And I think the difference is really the perspective of what you're doing. Like in the, I call them out because they have a technical function rather than a business function, if that makes any sense. Well, the reason, but it kind of jumps out on me because you mentioned platform tools only once and application everywhere else. So either they're the same or they're different and if they're different, then where does platform tools live differently than applications aside from that one paragraph? Yeah, I'm not sure there's a difference. If we say, I think that suggests actually, sorry. If we say that the monitoring, I think that those technical monitoring is really just another half. I'm fine with that and just strike that entire paragraph. Yeah, I mean, I think that's addressed in three and four, the platform tools part of it. Well, I'm not saying it's just when we remove the entire paragraph. I was actually just suggesting we remove the three words on line 85. Well, actually, I think the whole paragraph is addressed in sections three and four. Like it's redundant and therefore confusing. Yeah, I think we can drop the, we can, I was on the, this was the last reminder of a whole set of things that I had in the write-up. So I was like, are you gonna trash this or not? So I wanna make sure I understand. Are you suggesting that that second paragraph is all about middleware and not the consuming application? No, no, this is about consuming applications but the consuming applications are not. I'm struggling with a difference between, maybe I'm struggling with a difference between what I would call business apps and platform apps. And then you can always make the argument of, well, platform apps are our business. So, but like between stuff that deals with purchase orders and stuff that deals with web server logs, that kind of a difference. And the only thing I why I put that in here is because people might need to find themselves in that paragraph. And I think that's where the mention comes from rather than a true distinction between business apps and platform apps. You know what I'm saying? Kind of. I guess I'm struggling with understanding the relationship between that paragraph and three and four. I could see some relationship between four but three has middleware. I don't see the relationship between that. So that's why I'm... No, this is, I think of these as platform tools and apps. These are endpoints. You have a fork and road and you are pulling events into your thing and you're doing platform level analytics in it. You want to do such stats. You want to do billing. You want to do any of those things. All right. So I think that the... At the last level effectively, that's the... So I don't think they are... These are still consumers. They are not... This is not middleware. Okay. Well, they could... Like Splunk, right? Is Splunk middleware? No. Well, I think that this is calling out specific purposes for the application that are not inclusive of all purposes for the app. So in a way, you could just add those things to this. Yeah. So it could be... You could say that... Yes, that would make a whole lot more sense to me. Okay. So I can say... Oh, so what I can say is... Or I can go and put the monitoring and providing... Yeah, I can basically take the second half sentence of that paragraph and just graph that onto the previous one. Yeah. I agree. And you can write graphed just because I like that word. I don't get to use it much. You appreciate those words more if you're not a native speaker. I wouldn't have known... monitoring the condition and operation of this institution. So I think that's a nice clarification so that we could just say... I will use that word, graphed onto... Thank you. Just for your clone. Thank you. It was very nice. But I still feel like if we don't refer to producing applications, then we're opening up... Well, maybe we're consuming directly from an Angular app, which I feel like is not what we're doing. But why not? If an Angular... I think it would be... If an Angular app is an application presuming... producing from other parties and is in this specification a producer application, then yes. But if it's not, then no. So the reason why I'm choosing... the reason why I'm choosing that wording like this is... What do you care about as a consumer? If I care about... I want to have the temperature reading from the sensor that hangs in the corner in that room in that building. I don't care about the app. I don't care about the software that produces it. I don't care about any of those things. I care about that sensor that currently hangs in that slot in that corner. I don't even care about the instance of that device. And if that device silently... or if that device kind of breaks and the tech walks into that corner, takes a new device, plugs that new device in, in that same slot, I still only care about that data from that place. I don't care about the device ID. I don't care about the identity of that thing. I don't care about the software I'm running on. I simply care about the context that the data comes from. Same thing with a person, right? I don't care about whether you write your comments on an iPhone or on Outlook or on whatever you do. I just care about it coming from you. So for the context, the application becomes immaterial, but the context that the application expresses becomes immaterial. So the application becomes... the application becomes... and even the device, per se, with that particular context interest, nobody cares about the particular... the particularities of the producer. The producer is just one of many that can serve in that particular capacity. That's why I draw that distinction, is that you are, as a consumer, expecting an event from a particular user, really, rather than expecting that event from a particular app. The app, the producer app, obviously, has a completely different perspective on all of this because it's all important for itself. But the consumer doesn't care all that much. So I'm trying to elaborate on that. I like that idea. I think you're getting at, if I'm understanding this correctly, the semantic nature of the event, right? It's very practically so that if you are having a conversation with someone on, let's say, you know, GChat or on Setsill Alive, or on Facebook Messenger or whatever, and you switch between the web interface and the phone interface, nobody really even knows that you're doing something different. But they're interested in the events that are coming from you. They're not interested in the events that are coming from that particular phone or from that particular web session. Nobody cares. So it's really, from a consumption side, and that applies to very, very, very many use cases, pretty much everything in industrial automation because everything is exchangeable. Just to name one vertical, you have a fairly much more abstract notion of what your interest is in events than to go down to the actual app instance or even device level. But you usually have a more abstract notion of the class of events or the context of the events you're interested in. It's not only this semantic meaning. It's really there's a, the context, the context is a term that's, I think is important there. It's not the meaning, it's not the context is the, is the top level concept. I guess I don't think there is meaning without context, but that's from my... Yeah, that's what I mean. The provenance of the event is significant. So there are cases where the provenance of the event doesn't even matter. Well, yes, I mean, it's that, how my assumption is when you say context is, it's the... An event is raised from a context, but that context may coexist at multiple places at the same time. And there's multiple, there's effectively multiple holders of that context, if you will, and they publish events on that context's behalf at the same time. But the producer is the one that decides what is the provenance of the event, right? Like it for your case where I'm making an edit on my iPhone or my Android or my web app, right? Like the producer of the event could decide that that's not significant or the producer could have decided that it is and annotate the event with that provenance. The producer acts on behalf of that context. So but now I feel like we're talking about the producer rather than the consumer. Yeah, so this is why I'm... Well, you started. So that's why I'm saying the... From a consumer perspective, purely from a consumer perspective, the producer's identity might just not matter. And it's very often that the producer's identity as an application instance actually very rarely matters. But mostly what matters more is the context that the producer is acting up on behalf of. But the producer is determining that context. Therefore, that... I mean, yeah, I don't particularly care what the producer is, but I care all the rules that the producer determines. Yes. So you're pushing... What you're doing here is you're pushing a requirement on the producer to be pretty clear about what that... to express what its context is. And so how would you distinguish context? So like this is semantic meaning of event, right? Like as determined by the producer. Wait, so... Okay. In the previous section, though, we already kind of defined context as well as classification. Do we really need to get into that again other than just to say... We have said that there is such a thing. Yeah. I don't think we need to say it again. I'm a little confused as to why we're smithing this paragraph. We already agreed to merge the two. What more needs to happen? Well, because like I don't know what it means for an application to consume events from a person. Well, I've removed the word person then for people. Right. So what I had suggested is that we consume events from applications of producer events. Well, no, we consume events from application producers. I mean, I'm sorry, from event producers. Yes, but... If we need to explain what... If we need to say what an event producer is, then we need to go back to the previous section. This section is about consumers. Yes. The producers, ultimately the producers persist the event, but here's the question of how much does the consumer actually care about the identity of that producer? Does the consumer really care about the producer and his identity and all those things? And it doesn't. The consumer's concern is around the context that the producer is acting on behalf of. That's what this is trying to say. It's... So the question is, what is the issue with... If we try to explain everything that that consumer wants, aren't we just repeating the producer context? No. No, because there's a different perspective here. The application consumes the event originally and lets stick with people. Right? What that means is, if I'm as a consumer interested in consuming events that are coming from people, I will need to go and collect events from all the places where that person that I'm interested in goes and has that same context. So if I'm running... And that motivates actually pops up. I'm interested in that person, writing into the context of a chat conversation that I have with them. If I have a chat conversation with them, I care about what the chat conversation and all the lines that are being transmitted as events emanating from that chat conversation. But obviously that chat conversation can now exist on three tabs in three different web browsers and can also exist on my phone and on my tablet and on my PC in an app in six different places. But it's all one chat application. So I care about receiving events from the chat context or from that person really in that case and not from, in particular, those six different kinds of applications. That's what I'm expressing here with consumer. My expectation is that I'm getting the information from the chat or from the information from the person or the information from, if it needs to be something more specific, but not from an application, from a specific application instance. I might, and I've made that a case here, application models and instances, but I might also want to have something from a more abstract construct that is then solvable using an intermediary that will help me with that. Okay, so you're... Well, I just want to be clear that like... For that paragraph, I just paste it in their work. I'm a little, I feel like we're getting, we're going down a rattle. I'm not quite sure why. No, well, I think that it seems like Clemens is trying to make a specific point. What did you just paste? Are you in the notes? Where are you? No, I'm in the chat, in the Zoom chat. It seems to me we started off in this discussion looking at the first two paragraphs of section two. And so I, at some point, I thought we agreed to merge the two paragraphs because the word platform tools in there was going a bit of a curve. So I merged the two paragraphs together. That's correct. And I'm happy with that. But now... Go ahead, Clemens. So, hang on. So the first part actually originated from Event Produce... No, no, no. So I'm actually not happy with that edit because I didn't see the first part. Because what matters here, what matters here, what I'm trying to express, what I'm trying to express is that the consumer cares about the... It doesn't care about the producer itself. The events are all produced by producers, obviously, but it really cares about context. The consumer, if everything is one-to-one, right, then we don't need to go and do anything because then we're not having a pop-up system. So can I make a recommendation, though? Because if you go two paragraphs ahead, down to line 92, you then start talking about basically what the consumer application is interested in, right? And that's, I think, where you should start talking about why context matters and stuff like that. But in the intro paragraph to what a consumer is, I don't think we need to get any more complicated or detailed than to say, they're the receiver of these events that we just defined in section one. Okay, then let's drop the originating from Event Produce completely. Because that is then implied. The point that I was trying to make is... That's fine. I was just trying to keep the same wording you had, but if you don't like the word originating, then there. That's fine. Okay, so then we're, you know... I just pasted another paragraph in there. Go ahead and just paste it in there, so I know. So I think it's, but it's not from Event Producers. No. It's because not producers are implied. Well... I would hope we have a relationship back to the first section. Maybe you say from Clemens? No. Why? Because that's implied, right? Events can't exist if they're not from producers. Okay, so yeah, drop from Event Producers. Yeah, because they consume events. That's fine. Okay. Okay. So then this goes into the details. Okay. So then the consumer application might reside. We already... Yeah. I can adjust that. Yes. See above. So then, consuming application will typically be interested in distinguishing events such that the exact same event is not processed twice. Identifying. Also, can you add numbered lists? Just because I think it helps. Discussion for next time. Then identifying, selecting the origin context or the producer assigned classification. I think that's the point you were making. Yeah. And then identifying the temporal order. Yeah. And... So that's one... That's one where... Let me just make a comment why I expressed it that way. Relatives to the originate context or relative to wall clock. So there are cases where you are emitting events without having a clear notion of what the wall clock is. And so you're using some reference thing that is not necessarily an accurate UTC clock. And that's why I put that in here as a thing that you might be interested in. But really what we're interested in often is not the actual time Right. Maybe we could say like, because it might... I mean, we could say this like, you know, maybe it's like which could be clock time or sequence number. Yeah. Could be a sequence number. Because the clock we have in there. I think that's a good point. Because some things don't have time, but they have sequences. And that's come up here as well. So we have new people on the call. Mark and Stanley, you want to just do a quick... Mark, you want to let us know who you are and where you're from? Or what context makes you interested in Cloud Events? Well, I've been on the serverless working group for quite some time. This is Mark Peake from VMware. Right. And just where we're doing as a round of introductions, why you or your company is interested in Cloud Events. For the new folks. Sure. It's important because we want to be able to have a lot of multi-cloud, cross-cloud connectivity. And we have a project called Dispatch, which is working on Cloud Events to be able to broker those between services. Great. Thank you. And then Stanley. Hello, everyone. Can you hear me okay? Yeah. Perfect. So I am here from Oracle. We are also interested in a bunch of scenarios. Probably one of the bigger ones is the multi-cloud, you know, interoperability of events. One of the things that we've taken a very interesting tact towards is there's no differentiation between our services and customer services in Oracle's Cloud. So anything that our services do, our customers can reasonably expect to drop in their own service. That could do the exact same thing. So we're taking a philosophical statement, which is when services communicate with each other, events is the language they speak. Great. So we are... I'll zoom back out. Thanks for the introductions. I think Doug is capturing things in the notes. So we have... We're talking about the different things a consuming application would be interested in. And Clemens and I and Doug have talked a lot. So we'd love to hear from other folks in the call, whether you have any additions or thoughts about these four things. Sarah, we only have about 12 minutes left, I believe, on the call. And I'm wondering if you could just kind of inform everyone why this is important again, kind of why we're focused on this right now. And then also how is it going to help us resolve some of these source conversations? Yeah. I think that's a good point. So what... I mean, I think the top level goal is to... We did the design goals were... In my mind, to really distinguish cloud events from other kinds of events, like just any asynchronous messaging. And I think that was helpful, but we needed to get one level deeper to really align on how we describe our systems that produce and consume events and allow those things to be decoupled. So we're trying to... I think this is a sort of easier way to get at the shared language before we start defining attributes in the spec. And ideally, we'd be able to use these as a way to say, if we can't do these things, then we must make a change to the spec. And that should get us to an interoperable state. Is that a fair summary, Allison, you think? Yes. Yeah, I think that's great. And just curious, when are we resuming the event source conversations? Where is that? What is that taking place? So we will... We want to get through this narrative, this discussion. We are talking again at 9 a.m. tomorrow after the TOC meeting. And if we have extra time, we'll talk about source. Yeah, I think this leads to a source discussion and we should have that very soon because ultimately, what source... Resolving the idea of what source is or what source represents will lead us fairly quickly to, I think, a breakthrough in terms of what properties we really need. I hope they do what it does. Yeah, I see this. I'm really interested in having this clearly resolved this week. Yes, I believe the same. I think our goal here is to get this to an initial version right away. I think all this effort that we're doing around the usage scenarios and design goals, absolutely essential to helping us. But I also think that just resolving some of these event source conversations quickly, of course, will help us get to that version sooner. So my hope is that this detailing of what a producer and consumer is will then just make it really easy to talk about source. Okay, I hope that too. Yeah, and at the very least, having the events are such an ambiguous topic. Having a single paper or a single spec that really defines how major industry influencers like Microsoft, Google, IBM, Oracle, and SAP and VMware all think about events, I think, will be creating a lot of value and clarity for a lot of people in general. Okay. Shall we then run through more of these points? Yeah, does anybody else have any things? And then I think there's these some cases, right? The application calls back. The consuming application might want to call back. See, that is not necessarily a callback. And I'm careful about that. So some cases, the consuming application might be interested in obtaining further details about the event subject from the original context, like obtaining detailed information about a change object that requires privileged access authorization. That doesn't mean call back. That means you might be able to come to that context and to the subject of inside of that context from an angle that you already know. So you get notified through some mechanism that a new file has been created in a blog for you. Then you have to come through the front door for your blog API to go and walk up to that, walk up to your account that you got the alert from and then walk into that container and find the subject of that notification that means that file and get it. That's not a callback in that sense of messaging, but it's really, it gives you enough context to go and get with your authorized access data about that event. And then, so that's, I think that's different from a callback mechanism. Correct. I was using colloquially calling back to the originating context. I think the word you have is... I'm just a messenger and therefore I'm triggered by those terms. Okay. Exactly to the point why these words are helpful. And then the last sentence is consumers interests motivate requirements for which information producers ought to include an event. That's a clarification that I'm not sure we need, but it's really, it's the producer, it underlines the point that the producer out of their own, out of their own drive might just go and throw some stuff on the wire without much structure, but it's really that the consumers interests are motivating how that information ought to be shaped. And it was an interesting point, it was an important point in my head. I think it's helpful, right? Because this is grounding the specification, right? And we would not just draw from the point number one in understanding what the producer needs to supply in the event, but we're drawing from point number two. Yes. So this is the point where I'm making where like what the producer puts in the event is really motivated by what the consumer needs. Yeah. So Clemens, can we go back for a second to the first bullet there on line 103? I just want to make sure I fully understand. Okay. Now you're not talking about additional information within the event context payload itself, are you? No. So let's say you have just created a new... So I'll use an example just to chime in with a different winner. Okay. So like somebody creates something in Google Cloud Storage but maybe is consuming the event from something outside of Google Cloud, right? Inside Google's Cloud we might have a specific way of calling back to Google Cloud Storage but there has to be some way to say it was this specific blob that was modified and then the consumer may want to call in to need some kind of a reference, some kind of a context that allows them to get more information or act on that object than was potentially in the event itself. I had a more like a business level scenario in mind like think of an HR application that raises an event that a new employee has been created in the system. The event may actually raise only as much as an employee ID because everything is PII and then only an application that is authorized to go and get at that PII is then doing a call into the application to get the detail out. Okay, I got it. Thank you. I think actually including that might be helpful. You like that? Okay. I really like that. HR is good because everything in HR is obviously secret as much as we don't like that but that's what it is. I think what threw me was the wording. Correct me if I'm wrong but allow me to paraphrase to make sure I'm fully on the same page as you. The first part when you say obtaining further details about the event subject from the originating context, I think what you're saying there is from the context that's in the event the consuming application may want to go to someplace else probably the original spot to get more information and the mechanism or the place it's going to go to is within that context of the event. Yes. I have to go and sit and over those paragraphs maybe a little bit more. Okay, because the way I originally interpreted was all the information that they're going to be that they're interested in is within the event itself and that's not what you meant. Dave, that's going to have a pointer in essence back to someplace else. Yes, correct. Got it. Okay, cool. And that is really up to the producer what they choose to put in the event. Yes, and they go and withhold information just because they can't share that with everybody in the PubSub audience and then they say, well if you didn't want to have more then just come back to me. And that's something that I have this as might here as a secondary. I broke this out as a second thing mostly because I think this is something that the application really decides and the application needs to go and deal with as a pattern but it's not necessarily something that we have to address as a first order construct in the standard itself. I actually don't think this will affect the standard but it's just context for people to think about the cases, right? And this is allowing for somebody to have a reduced amount of information in their event. Yeah, exactly. Because the point here is I think this is a super common pattern but I also think that all the context that you need to go back to a different place is split between your application and the payload data and it's really an application level concern. I just want to call this out as a common application pattern but one that I don't think we will have to go and address in our common properties. Yeah. And again, it's context. Because a lot of that's what we're doing here. We want to capture the shared context that we've been achieving in the working group meetings. So it's nine o'clock and I will submit this and so people can look at it and chime in more and then we'll go to the next two sections in the meeting tomorrow and if we get further then we can talk more about specific attributes. Yeah. So other people on the call who didn't talk as much, please, please chime in if you had additional thoughts on this, particularly on these two sections but on the whole thing in between now and tomorrow. Great. Thank you. Thanks everybody. Thanks everyone.