 Morning Rachel. Good morning. How are you? It's an awesome Friday Do you have plans for the weekend? Relaxing before I'm going to Armenia next week. So oh Wow, that's cool. Yeah, we have a site in Armenia. It's gonna be a long trip. How about you? I'm going to Vegas this weekend, but it's a not exciting trip. It's just Oh, hey guys, it's Doug. Hey, Doug Honestly Hey, Sarah, you're hard to hear. Is that still hard to hear? No, that's better Morning Good morning 23 Let's uh, while we wait for people to come. Um, I'm just I'll just add to the attendees The guys here here Here yeah, I'm here. Just quiet Rachel Yeah, Louie Yeah, I think you've met before but maybe you can Introduce yourself Yeah, I'm from You cut out for just a sec, I don't know if you did I'm from Huawei And then you a Yes Mark yeah Yeah And you're from the emory the emory. Yes, I am slowly remembering and then Austin Good morning And Austin you're from serverless ink serverless ink and Mark Fisher Hello Mr. Pivotal Fisher from Pivotal Great did I get everybody I think so. All right. Thanks everybody for joining me. Um and joining us in this Epic scoping exercise I what I did it This morning is pull out the two the consumer and the producer which I think are The bits that are Pretty clear in the usage scenarios Which we went over in detail on Monday and Tuesday and I had the only things whoops Files changed Which doesn't have my latest commit Sorry, hold on a sec But what I was proposing to do is to have a To make sure we're aligned on those and um And then those have those be a separate pull request and then dive into the discussion of Uh, why this is not I can fix it up later But what I attempt to do this morning, but it's not in this pull request Is um To just have this be Um The consumer and the producer And then separately talk about the framework in the middleware and see if we can get further on that And um and then do that as a separate pr. So in worst case, we'll have The consumer and the producer established and then we can Talk about the other things does that make sense? Yeah, that sounds good. So Sarah one of the um One of the concerns I have is that I've heard from clemens that microsoft is Not in favor of pulling it out mainly because They believe they're removing the middleware stuff Basically ignores their requirements and so I'm wondering whether it would be useful to rather than looking to split at this time if we couldn't focus on Seeing if we can come up with concrete textual changes To the current pr That would get everybody to the point where they say yes, it's good enough when we can move forward Let's talk about that. Um, so I am I've heard that we want cloud events to be used in the um like for a web hook Where an application talks directly to like a um a consumer Talks directly to a producer with no middleware Okay And that that's why I thought we could do this Directly and I think that the number one and two says that and so that that was my thinking that we I'm happy I know that we also have stakeholders and google is one of them Where middleware is important So I'm fine with that Approach I just wanted to clarify that we are also meeting the needs of stakeholders who don't have middleware Yeah, I I I don't think anybody would question that I would just rather it just seemed like we were I got the feeling based upon of the uh Many discussions we've had this week that we were fairly close to agreement on clemens pr and that if we could just Get some minor wording changes. We may be able to get over that That threshold to saying yes, it's good enough and we can move on All right So let's talk about it. So I think they um, I thought we were very close on clemens pr But then I was surprised at the implication that this would require topics in the definition of the event And um, we had talked about in the past that there were several architectures which Had a higher level of abstraction on top of topics For um, you know, google has trigger specifications where you can specify a filter And I think that uh, nucleo also has um a similar um architecture So My interpretation of all the texts that are putting in there Is not to force us to define what's in the spec at this time They are simply there to explain Some of the some of the thoughts that have been running through our heads in terms of what of the use cases we'd like to try to support I don't believe there's anything in there that mandates. We will have a topic I think that's a discussion for later when someone actually proposes. We add a a attribute called topic So, um, I just want to so this is the clarification that I want to make in this in this document Um, why don't I share my screen so you can see which I've which I meant to be Yeah, if you can show us the exact line of text you think Just mandates that we're going to be adding a topic. I think that'd be useful Yeah, I think that there's I don't think it's I think it's just not clear Um, so I'll share my screen um, I think that that um, so Basically, there's the middleware routes events from producers to consumers or onwards to other middleware Applications might delegate certain tasks um from consumers requirements to the middleware And then it says that to satisfy these needs. Oops. Sorry The middleware is interested in these metadata discriminators um so I think that um What clements has argued in the past when we talked about triggers Was that those don't need to be in the event Because those discriminators Could be only addressed in the middleware Not in the event So I'd rather not I'd rather not focus on what he said. Okay. I'm saying that it is a it is a reasonable Assumption that these classifications right Could be addressed by the middleware without being in the event The um the Um that there would be um Would help if it said if there was a word or two in the beginning a line like on 140 That's said middleware will be interested in things like and then the list Not implying that it's more like a list of examples as opposed to something close to normative so I think it's that um what What I'm trying to understand is how And maybe there are some people on the call who have topic-based systems who could speak to um how I'm trying to understand how this Description got us to we need topics and so I feel like There are I and what I'm trying to address Is this continued Of confusion. I'd like to be able to point to something in this description that says um These are not messages like if somebody says why aren't we calling this cloud messages? I'd like to be able to point to a session and it says this is why they're not messages Hey, sarah, um, I don't think anything in here actually denotes. So this was based off poll 117. Is that correct? Yeah um, I think the the source of confusion maybe that happened yesterday was the poll request that um you rachel claus Had a fair amount of pushback on was actually 95 um, this poll request hasn't changed From the standpoint of defining like a producer a consumer Middleware framework. Um, if you search for the word topic, I'm relatively certain it's nowhere in in this No, it is not in here. That's that's what I just wanted to say There's to me a little bit of a decoupling here from the science defining kind of the high level Persona roles, right that we talked about versus do these actually force us into Having, you know, topic be one of the required metadata fields on the event envelope that to me was kind of the there was a little bit of ambiguity as to whether or not While we were talking about 95 or 117 So I'm talking about um, I thought that on monday and tuesday, we were getting to conversion and then um, There were a whole bunch of questions that I didn't anticipate so um, so I think that you know folks feel that I mean These metadata discriminators are really purely about the event itself as given by the examples um And then the the wording was changed here so that it It's clear that um The um The producer I believe this is clear that the producer doesn't it doesn't imply that there must be middleware Producer decides if it's going to send something to middleware, right? Yeah, absolutely, right like the ultimately to me the producer Doesn't define where the message is going, right? This is not a point-to-point system. This is purely a Like an in immutable point-in-time observation was taken Of a thing, right? And I'm going to make people aware of it Make others aware of it right And that that's so in that I think kind of segues into the idea which is When we had the idea of so again, like I don't want to confuse 95 with 117 or now what is 122 But the idea then was there was some confusion around the word source And I think we should scope that Source versus topic was brought up. Um, but again, I think that is a totally separate piece of the conversation related to poll 95 I think 117 really just defines the high level act not even actors high level kind of personas Yeah, I would agree and sarah. I think it might be useful to focus on 117 instead of 122 Sir, this is is now identical. So I will go over here a few Yeah, just just to make sure I don't personally have any Like one way or the other it doesn't matter to me if we If it's 122 or 117, I think at the end of the day, like If we settle on a you know, the the correct set of words that we believe convey The the personas it means very little to me which which pull requests got merged. No, I I was focused on the number It was more I wanted I wanted to look at what what clements was advocating for right as opposed to something that changed afterwards Which not everybody's had a chance to review yet So, uh, the thing that we're looking at right now, which is 117 and the conversation about middleware I have concerns about because it seems like there's not Alignment about whether or not middleware changes the event So sarah, can you hide all the comments just so it's easier to look at just the text itself and we can ignore the comments Right. Oh, here. I sorry. I didn't see that check. Yes So so rachel. Well, well, wait a sec. I started going mark So there there is a comment from clements that says none of the activities change the events semantically So that Is that in the text here? It's it's in a comment So I think that's that's 129 So I think that's the challenge is that I think they that we want the confusions, right and the questions to be addressed in this text Right. So so that's let's focus on rachel. What what is what is the bit of text in here that led you to believe That's something Incorrect could happen within middleware Um, it wasn't so at the top of number three. So like online 121 So do you want a good one? Yeah, middleware routes events Middleware routes events from producers to consumers are onward to other middleware So that leaves open like is it able to change it? Is it not able to change it? So I asked the question I just made the suggestion like without changing the event that it's not a semantic change Because it's like it's not verified in that sentence And then that led to a long discussion where like I was just waiting to hear the answer Like if it's rejected or if it's accepted, I'll have a different response and there was not a conclusion So I would I would like to just specify right there online 122 Either with or without changing the middleware So if we can Sorry, sorry to thrash you on this, but could could you turn on the comments? Sure real quick and and then go back to 129 I think this might actually be in this spec or sorry in the language that clements drafted online 131 You put in here transformation that changes the event structure like mapping from a proprietary format to cloud events While preserving the identity and semantic integrity of the event And then can we can we like decide whether or not middleware Is changing the event right so that says that The middleware can do that. It doesn't say that the middleware won't do the other thing So I think so okay. Maybe this is my point of view, but It seems to me when we start getting into saying what can and can't happen In middleware and stuff like that. It's sort of out of scope for us, right? We're defining an event format What happens before and after the event is sort of manifested to be compliant with our spec It's sort of out of scope for us. So I'm not really sure it's appropriate for us to say What middleware does or does not do? I think that the definition so this is the um, I think it's really important to get this right because this has been the confusion of discussions I I believe the intent of this pull request is that If middleware were to change the semantics of the event it then becomes a producer It is no longer middleware as we're agreeing on the terms here But I My point was just that I like I'm okay With uh, like I wanted us to get alignment like the goal of this document for me Is that we should understand each other's use cases and we should agree on what the terms mean And so I'm just trying to get to like I just want to know what we mean when we say middleware Not trying to I'm not trying to be prescriptive. I want to understand what people mean and it feels like that's not Um, like we we haven't aligned there yet Hey, this is going to sound more blunt than I intended, but I don't think it matters Um, be perfectly honest. Um, we have had many many conversations Only wait, let me let me finish. I I don't think it matters because ultimately someone is going to produce to be producing an event I don't care who that is as long as the person producing the event Perk puts the right information in the right spot I don't think it makes Difference whether they think of themselves as a producer a middleware a framework or anything else As long as they put the great data in the right spot. They can think of themselves any way they want I think so I think that there there are implications of this That like it's not it's not just wordsmithing like like clemen's last comment is And this is why source is the wrong attribute So like I think a lot of people are reading more into this like people like it's it's like aligning world views and then from that We can write a spec I would actually echo that sentiment as well, right like when you open the door to say I as you know quote unquote middleware can say I'm going to change parameters on the event It is now the job of the consumer to detangle Like well was this just the routing of the event versus the actual Initial emission of the event, right? I think you open the door for a lot of ambiguity Middleware is purely observational as I think what we're going for in this case And I think that's what you're advocating for sarah and exactly as well Which is the idea that if you're going to Change something about an event in any capacity, right like you have Ultimately not you're not middleware anymore, right? And that's what we're trying to define middleware is specifically the like a Kafka broker or A mesh network that is literally just forwarding packets, right? Those are the sorts of things that we're saying like if I don't even change go so far as to change source Right the source of the event was a sensor, but I'm an api gateway So there's there's some ambiguity there as to Okay, now do I change the source on the event to say that it's coming from me versus it's coming from You know the original sensor that was I think clemens intent With that I think ultimately what this says is a producer creates the event middleware Fords it in some capacity or fans it out in some capacity. There is observation And routing there is no change outside of format changes, right? Like moving between message pack versus json Yeah, that's what I would have expected and then that's not what seems to be happening in the conversation. So like I think we should just Like we need to we need to like decide on that one. And then I think this like That like that's my main concern with this with the usage scenarios and after after we like have agreement there I would like I think it's probably good to go for me I think clemens actually in one of his comments indicated that the Event context metadata would be immutable. So I mean that that implies that middleware doesn't change the the event context But then he says in the comments for like in these comments right here that he does like he does imagine the middleware changing Changing things and making a semantic change. Doesn't he well, maybe we can move forward with like The alignment in the rooms because I think there are other folks who have similar systems To microsoft too. Maybe I represented here who could Yeah, I'll speak up. You know, we have a product called the event gateway which seeks to be a middleware solution for cloud events and You know at at this time, you know, I I do think we have a handful of features that we'd like to implement that we've heard from users that That do transformations on the event structure, but again, don't change the semantic integrity of the event And I think that that's that's a pretty good rule that that we'd personally like To be able to to be able to do that I am pretty hesitant to get super prescriptive about this actually at this time because it's it is so early That's something I'm I'm currently feeling as I listen to these conversations But I do we definitely do want to do some type of transformative features But again, not to change the semantic integrity of the event, but just to add on potentially other properties Or or change formats Yeah, and to to sort of address your your comments stevo if if I think those stevo or is it stanley? I'm sorry somebody If if a middleware Is going to be making some changes to the event and then there's the whole question of well is does it now become the source or not? I think the way that decision would manifest itself would be to Propose a change to the specification itself relative to the attributes that we have right because if someone says Well, I need to have additional information beyond the original source ID or whatever they're talking about, right? Then they're going to advocate for potentially a new attribute to be added And they're going to have to make a case for for why that used to get added And I think that's the best way to resolve these kind of discussions is by saying, okay How would we resolve your particular use case? Can you do it with the existing stuff? Do we need to add something or change something? I'm not sure as as call to saying I'm sorry as ostman saying is being that prescriptive Just in defining the scenarios that you know guided our thought process I don't think is necessarily as productive as as people some people think it is That sounds really reasonable to me. Um, would it be useful if we captured middleware scenarios separately? Like if we just like Moved on with this with this pr and then like maybe even pulled out the middleware And and just like collected the middleware requirements elsewhere I'm just my best the channel clevins here Um, they would object to a pr that pulls out middleware because that they view that as A significant portion of their requirements. Yeah, I don't want to say I don't want to say that like we shouldn't capture middleware requirements. Just that like There are more middle row more middleware requirements that aren't being included here. Well, um, let's just pause on that for a sec I want to address the question that Doug raised um, which was why you know Why is this important? And what I want to call back to is the many discussions of what is source, right? Like Where if we can agree that the middleware that that like whatever the source Except for like formatted encoding the sources Um met whatever context it provides is immutable Then I think that that does move the conversation forward I think there is some need to say if we say that middleware could do anything Then we start to have a third actor in the event that um Right, like I completely agree with this line of thought right like you've you've added puppet master or something, right? Like I'm I'm now going to look at events and decide whether or not they need to be mangled um, if anything you can relegate The scope of what middleware is allowed to change to our extensions, right? The actual envelope as it was initially created is immutable And but we allow for extension, right and and to go so far as to the data payload is also immutable, right? extensions, however, right this this, um Basically generic hash map that we've allowed is the only thing middleware is allowed to touch That's exactly what what Simmons stated in his comments. I mean that's a fair point I'm thinking this is sort of the the compromise. I'm attempting to to propose between the two right, which is You know there there has to be some notion of you know an event was produced Middleware really can't reach in and mangle it except to add context that potentially indicates to someone that you know it An event hopped along a route to get to where it's going I'd like to uh Make a comment on this which is if we read number one And at the bottom it talks about A use of middleware Where the weather station is producer, but the intermediate gateway Is actually creating is the producer of the cloud event And this is this is a use case that uh, we're doing inside of our project dispatch where We are taking foreign events And turning them into cloud events Same We're gonna we're gonna be doing that as well Right and and and and so so there is a reference here where It says that the inter this intermediate gateway plays a middleware role c3 if that's the intent of What clonence was talking about Then that is a very valid use case for what both uh us and and I have inside of the event gateways that we have So I think that word I'm sorry. Go ahead. I'm sorry. I defer to you um, so the question I have is if um Like does that mean that we're saying middleware can choose to be a producer or a Transport I would actually argue that that sentence is incorrect in in part one I think if you are constructing the event You are the effective producer On behalf of right the context in which an event took place. This was a similar question I was thinking of it from an iot perspective right like where I have access to Like 12 bits I can you know raise or lower And ultimately like I and a gateway is going to say oh like this bit was lowered means low battery, right? um, you're producing the event in the on the context or on behalf of Right like the actual sensor or the actual weather station or something along those lines to me I think this paragraph should be rewritten Based on the discussions we had this week well Again, you know, we're trying to put words into clements mouth in terms of what he meant here uh, but I if if he was deriving a lot of meaning within that middleware role based on uh, this transformation Between that original producer that may not produce cloud events and then the gateway Producing the cloud event that might be part of the confusion here Sure, I even think it was in the paragraph. It's inconsistent right like you're saying he actually says the gateway publishes the event Well, it is I think it's a nuance of it produces an event Maybe not a cloud event I think what you're what I'm hearing then is that the weather station has the proprietary Right like event that contains data indicating weather conditions every five minutes And the cloud event is what's coming from the gateway. Is that what you're arguing or am I misunderstanding? Let me try a different a different one which is I I can hook up to sqs and Wait for events coming in through sqs And then I can transform that into a cloud event To sqs. They are producing an event Um, I'm gonna chime in real quick with one other note. I don't think we've covered from the perspective of middleware Uh, you know one thing I'm worried about with us being so prescriptive here in this language is We're going to preclude our ability to be able to listen to the market Um, and now the way our middleware implementation is going to work is that users are configuring everything so So nothing is going to happen by surprise They're going to be able to configure exactly how events are treated and converted or if they're transformed within our gateway, we want to make sure that we We do give them some level of flexibility there because we also because we want to enable our system to kind of Listen to users And be able to accommodate a lot of functionality So all this stuff anything that happens within the middleware, you know, we we'd like to do a lot of experimentation in that area And again, it's going to be configurable completely by the user. So nothing will be will be happening by surprise um, I do worry as we kind of Dig in to this language and try and get more and more precise That it's going to stray from what I think some of the middleware implementations will Will actually look like Is there is there a way to say that because I feel like that's a very interesting point And if I were reading this document later, I wouldn't know that I wouldn't I wouldn't know that we're trying to be um I I would read it as ambiguous rather than purposely ambiguous That's a fair point too austin can I ask a kind of dumb question just given my context um Is your intent to supply sort of like etl-ish type workloads like saying like we will consume events Transform them or perform aggregations or projections and then potentially persist them somewhere else Um, that is something that we're considering Uh, we're uh, to be honest, we're considering a lot of things within the middleware So it is going to blur it is going to blur the lines between A lot of the things we're talking about here. I would actually argue you take on all three personas in that Respect like if I wanted to use you to simply route from a to b without touching the event You would support that I assume immediately and in that case you're purely mere aware in the case where your consuming events You know altering them significantly or insignificant and then producing new events You're effectively You know consumer transport and producer Right. We're transporting this particular instance is my I use the wrong word, right? Um, you're transforming and potentially, you know moving data So, I mean I I think the three personas might hold if only that you Are if you are willing to acknowledge that you are actually all three of them instead of just one of them Yes, uh, absolutely I mean, I think it goes without saying that we're all wanting integrity within Data integrity within all of these messages as we transform them or move them along the pipeline, but At the end of the day You know, there are there will be changes made Uh, depending on what the source is and what the destination is Yeah, and I I agree and I that that's why I get very nervous when I hear people I think they're implying that that our spec is in some way going to say A person in role x must not do this to the end So I think you can say that so what I'm suggesting Is that what we're doing is we're helping our conversations We're saying if you're in role x you cannot do that. Therefore you have to describe yourself As role y in order to have the conversation be more effective So if we say that so one approach is to say that the in this weather station example It decides whether it is the producer Or an or middleware And if it wants to construct required metadata then we refer to it as the producer So maybe it wasn't clear I don't think our spec can mandate what any implementation does aside from Mandating what data goes where? Whether and whether someone in one role chooses to manipulate an event in some way is out of scope for us I'm I'm suggesting that we have a common language for describing the roles based on what they do And anybody can do anything and if they do a certain set of things we describe them as a producer If they do a certain set of other things we describe them as middleware and it will help us in our conversations Right Is you guys are in violent agreement? Actually, it's like what what I would take away from this conversation I think sarah you're exactly right to say we're not going to be prescriptive about What you can and can't do we're simply saying if you do these things you are in this role Yes And to your point dug. I think that assuages your concern about getting too prescriptive about Specifics like we're we're not saying you can or can't do things We're simply saying if you do x you are a producer if you do x and y You are a consumer Or something along those lines, right? Yeah, I don't necessarily disagree with what you're saying Except based upon the last two to three weeks of going around and around and around I'm not sure I would agree with the claim that it's helping us focus Right, and that's why I would rather Put this behind us one way or the other And focus on people advocating for or against attributes appearing in the spec because in the end that's all that matters But doesn't this inform what attributes belong in the spec? No in sit. Well, let me put yes and no This seem entirely unrelated to you. So I think that we need to share Let me let me finish the reason I say no is because Everybody is going to have their own point of view in terms of what's important and what's not and everybody will Come to the table with their own perspective And when you argue for or against a particular change in the specification You will present your point of view relative to that particular change And that's all that really matters Right, whether you choose to agree with all this text in pr 117 Is is almost irrelevant because ultimately we're going to have to repeat this exact same discussions When we talk about the attributes because you're going to have to justify your use case for it We could also adjust this language if needed And we've already already said that this language isn't normative What what i'm trying to do is to move us forward in When we say middleware, what do we mean when we say producer? What do we mean so that because we've we've had this we've had many times We've had the api gateway conversation And many times and we've had new people come on board and have the same conversation again Where generally I think there is agreement that there is a The the common the most common use case Like is a dumb gateway that just says i'm doing format transformations and i'm passing one thing to another And that's um that has a one set of concerns Which are a lot of concerns like there's all these transport questions and encoding questions that we've deferred that we will get into That having an actor that doesn't actually change the meaning of the event is a useful concept in our conversations And so that's kind of what i'm trying to get at is that when somebody says I'm middleware that we know What concerns we're bucketing in there or we can say we call that You're in the producer role great now. Tell us all your concerns And so that we have that shared language for like because we have different architectures I think this is a helpful exercise Getting out getting aligned on a shared language is It sounds like a small thing, but it is it is so important to enhance collaboration And I think that what we have here is is pretty good. It's also going to help newcomers come and understand this better and navigate the ambiguous world of events So I think there's definitely value created here at the same time I'm certainly hearing a lot of folks Get more and more antsy to just go back to the attributes discussion and focus on that Is there any way that we could address any other comments regarding this pr and and seek to Seek to potentially close it by the end of this this conversation Yeah, I think one thing that would be really great Like one thing that's been really clarifying for me in this conversation is that we see middleware is being able to Assume any of the three roles. It could be flat middleware producer or consumer And who could include that? I think that would be very clarifying like it could be once in its in section three at the top of section three Um, or maybe it just goes At the top or the bottom. I don't know it could go in several places, but that's a important point I'd agree with that as well. Actually that is a nice piece of clarity I like that Is there um, did we decide on how we were going to change 117 since Florence is not open to changing this anymore? Are we going to fork it and hope he accepts the pr or I I can I can push I I could push commits to his pr. That's not an issue. Um, I Just need to know what textual changes For proposing um You let me to send a sentence I would prefer comments directly made to the pr that says change this sentence to this sentence the exact wording All right, I just want to add a sentence, but I will put it in here. Okay Um, so do you want to put it at the bottom or this is a I think we also decided that there would be um a change to the last paragraph of point one given that we are If something is producing an event on behalf of the original producer, we're considering them to be a producer I think that's a comment that mark left in the Chat as well. I can I can work on that comment if you'd like That would be great Because I think that would be very helpful in our conversations because basically I Believe me. I am antsy to get to the actual specification I just want to make sure that when we're talking about attributes We have this common language Um, so are you uh, Rachel and I don't know who is just speaking. Are you drafting? I'm ready in a sentence that I'm going to just add as a comment and that Doug can decide if you want to include Yeah, I mean with only but 18 minutes left on the call I'd prefer that we get to the point where by What would be the deadline, you know Tuesday morning or whatever it is Monday night that People have made the exact textual changes they'd like to see in the spec And then I can quickly run it by you know, microsoft to see if they have any objection to it going to their pr Because technically it is their pr And if not we can get it added in and vote on this thing really quickly And it would be great if microsoft had somebody else from clements team who would join the discussion in case there are questions on Thursday Yeah, I'm working on that. I believe they will have somebody there. Yes, super. Um, and that's okay So let's assume that that's going to happen And thank you rachel and did you make a note of who else was going to do? Oh, that's stan. Sorry stan. Thank you um, I want to um, there was a question that was raised in yesterday's conversation that wasn't answered which is Why do we have a separate framework section when we've already said that um There are there was like I think it was kathy who was saying that In the producer there were multiple roles, right? There's the platform serverless platform or you know, there's a the platform the application developer and those were collapsed into one role And so there was the open question of why do we have this separate frameworks role? And so um, clements, uh gave a shout out to you austin and so i'm curious Whether framework is different from middleware In terms of its needs Well depends on your definition of framework, of course, uh, you know, we have a framework that's a developer tool for provisioning all the configuration All the infrastructure wiring these things up so that they work together Um, and that's that's what our definition of framework is And that's certainly that's certainly a different a different role than the middleware um And it's a bit of an ambiguous role too So it could be it could be a lot of things And let me look at this language again so so like we have middle we have frameworks too, right? so we have on the firebase side like we have a sdk that does it takes the event and like, you know decorates it with all sorts of things and and um Has a bunch of ui and and developer tools around it and um I was originally sort of bucketing that in the needs of the consumer Right the consumer may may have that type of developer api framework or the producer might have it, right? And so I wonder whether the it would clarify it to members of the working group if the If whatever the framework needs are are the consumer needs or if it clarifies it have it separate That's fine, too. I just wanted to address that point that we didn't have time to discuss yesterday So the framework needs are the consumer needs Um Are there either consumer or producer like they fit into the other roles? I think our in our case they are consumer needs right because we have a consumer framework Um, and I don't know whether your frameworks are producer or consumer framework But I it feels feels like they might fall into one of the other three roles Okay, are you suggested that we get rid of We get rid of this persona Um, I'm suggesting that it might be I think that it's redundant with the other three And I'd like your feedback on that Hmm Is it redundant? Um I don't I'm not entirely sure at the moment to be honest Uh I have to think more about it and read through that language again. Um, so And if in doubt I would like to capture your use cases more so like Like if it does if it feels like they're different it would be great to like leave them in and Provide more detail about what they are Yeah, and just to tell you my perspective on this it seems that this um, the the sort of this metadata commonality Is really detailed in you know, there was a some this in this metadata discriminator up here For like aggregation. So kathy was pretty vocal about this need for classification Right, which um, and I think that many of our systems need Which led to that pretty precise description, which I think I'd just like to aggregate the same concerns in one piece of area of text if appropriate Uh, you know regarding the framework, um I'm not sure at the moment. I I think it there is a case for it being separate In the interest of moving forward though, I I'd suggest that We perhaps just leave it in and address it in the following pr Does anybody else who's a middleware framework developer on the call or? um Can hear me so One aspect that might be important for the spec or I think it is important is the interoperability. So uh, especially for the frameworks Austin I think develops so Um They they need to be able to run in many different infrastructures And therefore may also rely a bit more on the On this aspect as the other roads So I could also imagine to to have another pr later on. Um Maybe elaborating a bit more on this interoperability. I think that's that's the core goal of this the whole specification So far the description of the roads Um, mainly describes typically venting cases, but doesn't mention This interoperability at least not explicitly I think we have that in design goals Yes, there it is. That's true. Yeah it's just um Yeah, I think that maybe a scenario something Especially describing this for example in the event leaving one Uh infrastructure organization and and entering another one and and how to deal with this Yeah, I guess I had sort of put that in middleware camp right because if we get it correct across the wire Then it seems that the framework should be able to do their jobs And that a lot of but you know, like I want to be open to Um, you know what the right needs are of the folks involved Yeah, it just stepped over this aspect when thinking more and more about this this topic question. Um Because in in in that case you would need to to maintain a topic Hierarchy and a structure and that's typically done inside one organization but if events, uh um Leave one organization and are consumed by some other one Um, that gets more more difficult and and that way I stepped over this interoperability um, okay, could could we Let's see is I'm in favor of leaving kind of frameworks of language in as is Just just on that just so we can move forward. Is there um, Was there anything else major? that uh That would Would block this from from being uh urged and That people are concerned about Uh, I just added my comment on the Clarification for point one. I that was really it to reflect the conversation we had here otherwise No Yeah, I added the comments that I have also and I think it's good to go So, um, great. Thank you. Um And that is Point one So I can't find it right now, but in our last 10 minutes, um I the question for the group is um in terms of how we describe our systems are there, um Is this sufficient to clarify the scope of what we're doing? Um, I added another issue Because what I what I'm trying to do is when we get into discussion of the attributes, which I'm dying to do really That we're we can have really fruitful conversations about what we're doing and not get into Oh, you know like confusion about what what we're doing we can we can we can get into the how Rather than the what? Right, that's my goal. Like I'd like to have the attribute discussion to be how are we going to achieve something rather than Um with a shared understanding of what we're trying to do Um, does anybody have any thoughts on whether we're there yet or what? We would need to do to have really fruitful discussions on attributes I think we're there and I think beginning the conversation related to attributes will most certainly Help us find deficiencies, right? Like I think we just have to be open to the idea that we will revisit the personas and clarify as necessary but From a baseline perspective, I think this is a reasonable place to begin the conversation I think so too. I think we've got our our roadmap which provided a lot of clarity We have our design goals. We have usage scenarios. All this should help increase our focus And this also just helps any any newcomers come in Uh contribute to the effort really understand what's going on, which I also appreciate because that whole That whole journey is important so, um In closing that issue Do we feel that the um It sounds like we're saying that um, I think that it might be good To capture Somebody said at the beginning of this call This is not a point-to-point system where Specifying how to describe the events that are generated And um, I don't know if that is actually I mean it's in the design goals um But the design goals also talk about that these have to be used within a system where there's a consumer and um that maybe um We Maybe just adding that somewhere About our scope might help Doug do you have a sense of where We might specify that that I like I want to be able to point to that if somebody says You know like in the question. Why aren't we calling this cloud messages? I tend to think that the the current text that we have around scope and what we said In 117 relative to sort of our our guiding usage scenarios. I think sufficiently explains what's going on I don't think we need to clarify any more So the cloud messages question came from me in the it was in this discussion about topics. So um, I was just imagining this pr 95 goes through then you would have attributes for a topic subject. I think event id timestamp And if you replace the term event in these attribute names, then you would just have A message header not nothing specific for event. So that was my concern when I asked that question Right, but so that's a question on pr 95. Yeah, exactly. Just find your scope. So I don't mean that city to talk about that right here Right Well, I was fine with the goals here. I mean here it states that events and everything. All right super I just so I think that um, what we're proposing in this breakout session is that The usage scenarios Combined with the good design goals with these additional changes would address the scope With the with the like and maybe it might clarify things if we say in the roadmap that um, wherever this is, sorry um that um We that this is That To re font that, you know, like I don't know I think it's all I don't think we have to change this. I don't know if people feel like this is clear enough that people that will refine I think it's it's part of the spec and part of the point one milestone is to refine the spec. So it works I think we need to be explicit that The scope is not prescriptive about those use cases and they're only there as uh Example of how people might use cloud events Should we put that at the top of The usage scenarios Sure, we could put something like These these are meant as kind of general guidelines a lot of a lot of comment there Yeah, I think using them is like sort of guiding principles for the design Um, but not meant to be prescriptive as the only use of the cloud events So I would just ask if like three minutes left if someone's going to recommend a change to this pr Please suggest the exact text you want to see if it's more of a I don't I don't I just just in general if you if there are other things you like to see add later Whether it's this doc or another one I would strongly recommend a follow on poor requests to make those changes Yeah, I guess I should mention my My actual my gut instinct is that this shouldn't be included in the spec at all so I was just trying to find a way to um At least make that clear that it's not the intention of the spec to describe use cases for cloud events Clement also also said that this could be um, he didn't feel like this needed to be in the spec either So we could put this in the about section Yeah, I think I'm very first won't go we talked about potentially a follow on pr that extracts this from the spec But we wanted to get the text first and then forgot a placement later There I mean it helps to get the same language within the working group even if ultimately the Work is thrown away right or not included in the spec Yeah, then becomes context kind of like we have the status for a while and then we We refine it and now it's in the reading me and So we are we getting close um, so I think that's the the last point I wanted to make to austin Is there a time box for the final set of You know comments to be included that doug should bring into this specific or The the pull request right whether it's 117 or 122. Let's decide right now and then Can today be the Yeah, I completely agree. I was gonna say um is like what time is it now plus three hours Is the time box and then at that point doug will You know bring them in and You know, that's it How about how about like noon doug's time doug are you west coast? One minute. Yes 3 p.m. Doug's time Noon for everyone who's on a same time uh zone Oh I kind of like the idea one minute. Geez All right, I think we delete the pr all together it would only take one minute just point here All right, thank you everyone Thank you everybody. Oh actually I One last note. I wanted to make real quick. Um, I think we've done a great job bringing fantastic people together And outlining kind of what it is that we're doing right now But I will say I do worry that if we don't go directly into the attributes from here I am detecting I don't know. I'm getting a little concerned that we might lose people So I want to I want to stress that we go right into the attributes after this because I'm just getting a lot of direct messages and emails So I'm very anxious to do this what I was going to suggest on the call is basically No discussion about this issue and just go straight to basically a vote And then whatever pr is ready to go relative to attributes. That's the next on the agenda So, um, so yes, and I really liked the suggestion that we do a collection of attributes together Where they they're related to each other And sarah, I think that's a perfectly acceptable way to go But the best way to have that discussion is file a pr with what you'd like to see and as I said yesterday I will do so. Okay. Cool. That's all I'll ask. I'm going to be a nag about that one All right in terms of process I did add claus and stan onto the attendees for today Does someone want to take an action item to just write a couple of quick notes about What we discussed or direction? Doug sarah I don't know Go for it. I can do it if you want. That's not a video Thanks, Doug. Yep Secretary am I? Yes All right. All right. Thank you Is there assuming people have until what 3 p.m. Eastern to get their new textual change they want to see in there Is there any reason to meet again on monday, or are we basically assuming we're done? I think we're done with this pr. I do want to make a point that We have a lot of people in the group who are new And so when we get to the attributes one of the governance things that I proposed was that we give If there is a minority voice that we give them time to Demonstrate the problem that they are raising Rather than overruling their vote And so I'm going to propose I made a governance proposal at ages ago And I'm going to propose just that one small change to governance Because I think we want to give newcomers a chance to demonstrate What they're you know the use cases and we can time box it Okay, just let you know I think the governance is a very set of ruled allows plenty of time for people to do that But pr away if that's what you want it Okay, okay. Thank you Thanks, everyone. It's great. Thanks everyone. Have a good weekend. Yep. Bye guys for your weekend everyone