Add a meeting Rate this page

A

We're original.

B

Morning, how are you.

A

It's an awesome, Friday.

B

Do you have plans for the weekend well,.

A

Relaxing before I've gone to Armenia next week, so oh wow.

B

That's cool yeah.

A

We have a site that in Armenia it's gonna be a long trip.

A

How.

B

About you, I'm going to Vegas this weekend. It's not exciting.

C

Hey guys, it's Doug Hey.

D

Hi asleep.

B

Oh hey: there are you hard to hear. Is that still hard to hear? Look! That's better! Okay,.

E

Let's, uh while we wait for people to come, I'm just I'll just add to the attendees, um oh I see you're here.

B

Stuck here, yeah.

C

I'm here, just quite a bit Rachel.

E

Maybe you can introduce yeah.

D

I'm from.

D

Yeah I'm from Chloe.

E

And.

D

Then make you a wer.

E

Hua, oh yes, mark yeah.

A

Yeah.

E

And you're from be.

A

More.

E

Be aware, yes, I, absolutely remember, E and then Austin good morning good morning and Boston you're from.

F

Serverless Inc surplice.

E

Inc and Mark Fisher hello,.

G

That's preferable.

E

Great did I get everybody I think so all right thanks everybody for joining me joining us in this epic scoping exercise I.

E

What I did it this morning is pull out the to 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 have the only things whoops file has changed, which doesn't have my latest commit sorry hold on a sec.

E

But what I was proposing to do is to have a.

E

To make sure we're aligned on those and and then those have those be a separate pull request and then dive into the discussion of I.

E

Don't know why this is not I can fix it up later, but what I attempted to do this morning? But it's not in this pull request- is to just have this be the consumer and the producer and then separately talk about the framework of the middleware and see if we can get further on that and and then do that as a separate PR. So at 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.

B

So.

C

Sarah one of the 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 that removing the middleware stuff basically ignores their requirements, and so I'm wondering whether it would be useful to rather than looking to split 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 every way to the point where they say. Yes, it's good enough when we can move forward.

E

So I've heard that we want cloud events to be used in the like for a web hook where an application talks directly to like a a consumer talks directly to a producer with no middleware.

C

Okay and.

E

That that's why I thought we could do this interaction directly and I. Think that the number one and two says that and so that that was my thinking. But we I'm happy I know that we also have stakeholders and.

H

We're.

E

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.

C

I thought I. Don't think anybody would question that I would just rather it just seemed like we were I got the feeling, based on the many discussions we've had this week, that we were fairly close to agreement on Clements PR and that if we could just get some minor wording changes, we may be able to get over that threshold of saying. Yes, it's good enough and we can move on all.

E

Right so let's talk about it, so I think they I thought we were very close on Clements PR, but then I was surprised at the implication that this would require topics in the definition of the event, and we had talked about in the past that there were several architectures which had a higher level of abstraction on top of topics. For you know, Google has trigger specifications where you can specify a filter and I think that nucleo also has a similar are textured.

C

So my interpretation of all the text 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 I've been running through our heads in terms of what 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 extra proposes, we add a fee attribute called topic so.

E

I just want it, so this is the clarification that I want to make and in this document, why do I share my screen, so you can see which I, which I'm in yeah.

C

You can show us the exact line. It's X, you think just mandates that are going to be adding a topic. I think that'd be useful. Yeah.

E

I, don't think it's I think it's just not clear so I'll share my screen.

E

I think that that so basically there's the middleware routes, events from producers to consumers or onwards, so the middleware applications might delegate certain tasks from consumers requirements to the middleware, and then it says that to satisfy these needs I'm. Sorry, the middleware is interested in these metadata discriminators.

E

So I think that 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 middle, we're not in the event. So.

C

I'd, rather not focus on what he said. Okay,.

E

It is a reasonable assumption that these classifications right could be addressed by the middleware without being in the event, the the that there would be.

C

Would help if it said if there was a word or two in the beginning, a line like I'm 140? That 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.

E

So I think it's that what.

E

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 how I'm trying to understand how this description got us to? We need topics, and so I feel like they're or I, and what I'm trying to address is this continued method of confusion?

E

I'd like to be able to point to something in this description that says 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.

I

Sara um I, don't think anything in here actually denotes. So this was based off pull 117. Is that correct, yeah I think the the source of confusion? Maybe that happened yesterday was the pull request that you Rachel Klaus, um had a fair amount of pushback on was actually 95. um This pull request hasn't changed from the standpoint of defining like a producer, a consumer middleware framework. If you search for the word topic, I'm relatively certain, it's nowhere and.

E

That's.

I

That's why I just wanted to say there's to me a little bit of a decoupling here from Desai 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. There was a little bit of ambiguity as to whether or not while we were talking about 95 or 117, so.

E

I'm talking about I thought that on Monday and Tuesday we were getting to conversion, and then there were a whole bunch of questions that I didn't anticipate. So 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, and then the the wording was changed here so that it it's clear that the the.

E

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.

I

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 a and in a mutable point in time. Observation was taken all of a thing right and I'm gonna 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.

I

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 on, but again, I think that is a totally separate piece of the conversation related to pull 95 I. Think 117 really just defines the high level act, not even act. There is high level kind of personas yeah.

C

I would agree it's there. I think it might be useful to focus on 117 instead of 122 sure.

E

This is now identical, so I will go over here. If you.

I

I, don't personally have any like one way or the other. It doesn't matter to me: okay, if it's 122 or 117 I, think at the end of the day like if we settle on a you, know the correct set of words that we believe convey the the personas. It means very little to me which, which pull request got merged no.

C

I focus on the number it was more I wanted. I want to look at what Clemens was advocating for right, as opposed to something that changed afterwards, which not everybody's had a chance to review yet so.

B

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.

C

Sarah, can you hide all the comments just easier to look at just the text itself and we could ignore the comments right.

E

Yes,.

C

So sort of regional.

A

Ways.

C

Are.

A

Good mark, so there is a comment from Clemens that says: none of the activities change the events semantically, so that.

E

Is that in the text here it's.

A

It.

J

It's in.

E

The comments 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.

C

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 something incorrect could happen within middleware. It.

B

Wasn't so at the top of number three so like I'm, lying 121 Sarah, do you and I good yeah middle river 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 not able to change it. So is a question.

B

I just made the suggestion in life without changing the event that it's not a semantic change, because it's like it's not, 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 will have a different response, and there was not a conclusion so I would I would like to just specify right there on line 122, either with or without changing the middleware.

B

So if.

A

You can sorry sergeant thrasher on this, but could you turn on the comments, real, quick and then go back to 129 I. Think.

F

This might actually be in this spec or sorry in the language that Clements drafted on line 131 you put in here transformation that changes the event structure like mapping from a prototype prior to a format to cloud events while preserving the identity and semantic integrity of the event and.

B

Then can we can we like decide whether or not middleware is changing the event right.

E

So that says that the middleware can do that. It doesn't say that the middleware won't do the other thing. So.

C

I think so, look at me. 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 events is sort of manifested it to be comply 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.

E

The definition, so this is the I think it's really important to get this right, because this has been the confusion of discussions. 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. What.

B

My point was just that I like I'm, okay, with like I, want 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 submitted like not trying to I'm, not trying to be prescriptive. I want to understand what people mean and it feels like. That's not like. We haven't aligned there. Yes,.

C

Hey it's gonna, sound, more blunt I intended, but I don't think it matters.

E

Honest.

C

We have had many many.

E

Conversations.

C

Let me finish: 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 events 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 spots, you think of themselves any way they want. I think.

B

So I think there their implications of this. That, like it's, not it's not just wordsmithing like like Clemens last comment is, and this is why source is the wrong attribute, so I think a lot of people are reading more into this. Like people like it's like aligning worldviews, and then from that we can write a spec I. Would.

I

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 gonna 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 opened the door for a lot of ambiguity.

I

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 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 mill where 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.

I

Those are the sorts of things that were saying like if I don't some even chain 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.

I

Ultimately, what this says is a producer creates the event middleware forwards 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 a message pack versus JSON.

B

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, why I'm being concerned 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.

D

Clemens, actually, in one of his comments, indicated that the events, the context metadata, would be immutable, so I mean that implies that middleware doesn't change the the event context.

B

Then.

D

He says in.

B

The comments for like in these comments right here that he does like he does imagine the Moodle or changing changing things and making a semantic change. Doesn't he well? Maybe we.

E

Can move forward with like the alignment in the rooms, because I think there are other folks who have similar systems to Microsoft, maybe I represented here? Who could.

F

I'll speak up, you know we have a product called the event gateway which seeks to be a middleware solution for events and.

F

You know at at this time you know 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 events 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 personally like to be able 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.

F

That's something I'm I'm currently feeling as I listen his 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 events, but just to add on potentially other properties or or change formats.

C

And to serve address your your comments, do if, if I think I'll steal or is it Stanley I'm? Sorry, somebody if a middleware is going to be making some changes to the event and then there's the whole question of well? Is it now become the source or not?

C

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 they're talking about right, then they're going to advocate for potentially, and you active you to be added and they're going to have to make a case for why that used to get at it and I. Think that's the best way to resolve these kind of discussions is by saying, okay.

C

How would we resolve your particularly use case? Can you do it with the existing stuff to be? They had something or change something I'm, not sure, as called to saying I'm sorry, Dawson I'm saying is being that prescriptive just in defining the scenario is that you know guided our thought process. I, don't think, is necessarily that's productive. Is it yes, people some people think it is that.

B

Sounds really reasonable to me. 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.

C

I'm, just my best, the channel Clemens here they would object to a PR that pulls out the middleware because that they give you that is a significant portion of their requirements. Yeah.

B

I, don't want to say I, don't say that, like we shouldn't capture middle requirements, just like there are more middle row, more middleware requirements that aren't being included here well.

E

Let's just pause on that for a sec I want to address the question that Doug raised, 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, like whatever the source, except for like format and encoding, the sources meted whatever context it provides, is immutable, then I think that that does move the conversation forward.

E

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 right.

I

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. 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 say. The data payload is also immutable.

I

Right extensions, however, right this, this basically generic hash map that we've allowed is the only thing middleware is allowed to touch. That's exactly what.

H

Simon stated.

I

In his comments, I mean that's. This is sort of the the compromise I'm tempting to propose between the two right, which is you know there. There has to be some notion of you know. Event was produced middle we're really keen on reaching and Mangala, 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.

A

I'd like to make a comment on this, which is, if we read number one and at the bottom, it talks about a use of the middleware where the weather station is producer, but the intermedia gave me is actually creating. Is the producer of the cloud event?

A

And this is this- is a use case that we're doing inside of our project dispatch, where we are taking foreign events and turning them into cloud events.

F

Same we're going to be doing that as well right.

A

And then- and so so, there is a reference here where it says that the inter this intermediate gateway plays a middleware role, see three: if that's the intent of what Clemens was talking about, then that is a very valid use case for what both Austin and I have inside of the event gateways that we have.

I

So I think.

A

That.

I

Defer to you.

E

So the question I have is, if like does that mean that we're saying middleware can choose to be a producer or a transport I would.

I

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.

I

Oh, like this bit was lowered, means low battery right you're producing the event in the on the context there 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,.

A

Again, you know we're trying to put words into Clemens in terms of what he meant here but I, if, if he was deriving a lot of meaning within that middleware role based on 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.

A

Sure.

I

I even think it was in the paragraph, it's inconsistent right, like you saying he actually says the Gateway publishes the event well,.

A

It is the I think it's a nuance of it produces an event, maybe not a cloud event.

I

I think what your 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 understanding.

A

Let me try a different, a different one, which is I hook up to sqs and wait for events coming in through SQS, and then I can transform that into a cloud event sqs. They are producing an event.

F

The chime in real, quick with one other note, I, don't think we've covered from the perspective of middleware.

F

You know one thing I'm worried about with us being so prescriptive here in this language is we're gonna preclude our ability to be able to listen to the market and now the way our middleware implementation is going to work is that users are configuring everything so so nothing is gonna happen by surprise. They're gonna be able to configure exactly how events are treated and converted or if they're transformed within our gateway.

F

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.

F

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 of limitations will will actually look like question of the day is.

B

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 I would read it as ambiguous rather than purpose ambiguous. That's.

I

A fair point to Austin can I ask a kind of dumb question just given come 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.

F

um That is something that we're considering we're to be honest, we're considering a lot of things within the middleware sure it is beautiful her. It is gonna blur the lines between a lot of the things we're talking about here. I would.

I

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 male, where in the case where you're consuming events, you know altering them significantly or in significantly and then producing new events you're effectively. You know consumer transport and producer right. We're transport in this particular instance.

I

Is my I used the wrong word right, 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,.

F

Yes, absolutely I.

A

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 there will be changes made depending on what the source is and what the destination is.

C

Yeah I agree and I thought. That's why I get very nervous when I hear cool I think.

I

Good and fine, but that.

C

Our spec is in some way good I say a person in rolex must not do this to the end. So.

E

I think wow. You 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 Rolex, you cannot do that. Therefore, you have to describe yourself as role why, 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's decides whether it is the producer or an int or middleware, and if it wants to construct required mated metadata, then we refer to it as the producer.

E

So.

C

Maybe I wasn't clear: I, don't think our spec can mandate what any implementation does aside from mandating. What theta 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.

E

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.

I

As.

E

You guys.

I

Are in violent agreement, actually you think what what I would take away from this conversation, I, think Sarah you're, exactly right to say: we're not gonna, 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,.

J

And to.

I

Your point, Doug I, think that us wages you're concerned 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,.

C

And I don't decide disagree with what you're saying, except based upon the last two to three weeks of going round and round and round I'm, not sure I would agree with the claim that it's helping us focus right.

H

And.

C

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.

B

Doesn't this inform what attributes belong in this book? No.

C

Insight, well, let me put yes and notice that.

B

This seemed entirely unrelated, so I think that we needed.

C

To hear the mean, 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 team, the specification you will present your point of view relative to that particular change. And that's all it really matters right.

C

Whether you choose to agree with all this text in PR, 1, 1, 7 is, is almost irrelevant because, ultimately we're going to repeat the exact same discussions, we talk about the attributes because you have to justify your use case, for it.

E

We can 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 had this 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. We're generally I think there is agreement that there is a common.

E

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 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.

E

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 were 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 light, because we have different architectures I.

F

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 it's 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, certainly hearing a lot of folks get more and more antsy to just go back to the attributes, discussion and focus on that.

F

It's 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.

B

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 we could include that I think that would be very clarifying like it could be one sentence in Section three at the top of section three or more: 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.

F

I'd agree with that as well. Actually, that is a nice piece of clarity.

B

Is there did we decide on how we were gonna change 117, since it's not open to changing this anymore? Are we gonna fork it and hope he accepts the PR or I.

C

Think I can push I could push commits to his PR. That's not an issue. I just need to know what textual changes.

B

In dissonance I.

C

Would prefer comments directly made to the PR that says change this sentence to this sentence? The exact wording alright,.

B

I just want to add a sentence, but okay.

E

Sonar, do you want to put it at the bottom or this is a I think.

I

We also decided that there would be a change to the last paragraph of 0.1, given that we are if something is producing an event on behalf of the original producer. We're considering them to be repeat, I think that's a comment that mark left in the chat as well. I.

I

Can I can work on that comment if you'd like.

E

Be great.

E

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.

E

So are you Rachel and I? Don't know who is, just speaking, are you drafting I'm.

B

Writing lessons that I'm going to just add as a comment and that can decide if he wants to include yeah.

C

All right with only but eighty minutes, that's on the call I 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 Microsoft to see if they have any objection to it going to their PR because technically is their PR and if not, we can get it added in and vote on. This thing really quickly. I.

E

Know it would be great if Microsoft had somebody else from Clemens team. He'll join the discussion in case there are questions on Thursday yeah.

C

I'm working on that, if I believe they will have somebody there. Yes, super.

E

And then okay, so, let's assume that that's gonna happen and thank you Rachel and did you make a note of who else was gonna? Do oh.

I

That's Stan, sorry, Stan.

E

Thank you, I wanna. 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 there are, there was like I think it was Kathy who was saying that in the producer there were multiple roles right, there's a service platform or you know, there's a platform, the application developer and those were collapsed into one role, and so there was the open question of.

E

Why do we have this separate frameworks, role and so Clements gave a shout out to you, Austin and so I'm curious. Whether framework is different from middleware in terms of its needs.

F

Little depends on your definition of framework. Of course, you know we have a framework, that's a developer tool for provisioning, all the configuration all the infrastructure or wiring these things up, so that they work together and that's that's what our definition of framework is and that certainly that's, certainly a different. A different role in the middle layer and it's a bit of an ambiguous role to it could be, could be a lot of things.

F

And if you look at this language again so.

E

So like we have middle, we have frameworks too right.

E

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 has a bunch of UI and and developer tools around it and 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 a bit separate.

E

That's fine, too I just wanted to address that point that we didn't have time to discuss yesterday.

F

So the framework needs are the consumer needs.

E

They're, either consumer or producer like they, they fit into the other roles. I think our in our case, their consumer needs right because we have a consumer framework and I. Don't know whether your frameworks are producer, consumer framework but I, it feels like they might fall into one of the other three roles: okay,.

F

Are you suggesting that we get rid of we get rid of this persona I'm.

E

Suggesting that it might be I think that it's redundant with the other three and I'd, like your feedback on that.

D

mmm

F

Is it redundant.

F

I, don't.

F

I'm not entirely sure at the moment to be honest, I have to think more about it and read through that language again, so.

B

I would like to capture your use cases more so like it 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're yeah.

E

And just to tell you my perspective on this, it seems that this, the sort of this metadata commonality is really detailed. In you know, there was a some in this metadata discriminator up here for like aggregation, so Kathy was pretty vocal about this need for classification right, which and I think that many of our systems need which led to that pretty precise description, which I think I just like to aggregate the same concerns in one piece of area of text, if appropriate,.

F

You know regarded the framework I'm, not sure at the moment. Are you I think it? There is a case for it being separate in the interest of moving forward, though I'd suggest that we perhaps just leave it in and address it in the follow-on PR.

E

Does anybody else's a middleware framework developer on the caller.

H

um Can hear me so um one aspect that might be important for the spec or I think it is important, is the interoperability so especially for the frameworks Austin I think developed, so they they need to be able to run in in different infrastructures and therefore may also rely a bit more on D and this aspect as the other roles.

H

So I could also imagine to have another PR later on. 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 roles um mainly describes eventing cases, but doesn't mention this interoperability. It is not explicitly I.

F

Think we have any design goals. Yes, there.

H

It is that's true here, it's just some.

E

Yeah.

H

Scenario, something especially describing this, for example, in event, leaving one infrastructure organization and and entering another one and how to deal with this.

E

Yeah I guess I 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 you know what the right needs are. The books involved.

H

It just stepped over this aspect when thinking more and more about this. This topic question, because in that case you would need to maintain a topic hierarchy and structure and that's typically done inside one organization. But if events leave one organization are consumed by some other one that gets more difficult and then that way, I stepped over this interoperability.

F

Okay, could could we, let's see, is I I'm in favor of leaving kind of frameworks of language in, as is just just on it just so we can move forward. Is there was there anything else, major that that would would block this from from being a merged in that people are concerned about I.

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.

B

I did a comment that I have also and I think it's good to go.

E

So um great, thank you, and that is.

E

So I can't find it right, but in our last 10 minutes the question for the group is in terms of how we describe our systems are there?

E

Is this sufficient to clarify the scope of what we're doing 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.

E

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 and with a shared understanding of what we're trying to do?

E

Does anybody have any thoughts on whether we're there yet or what we would need to do to to have really fruitful discussions on attributes I.

I

Think we're there and I think beginning. The conversation related to attributes will most certainly help us find efficiencies 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.

F

Think so too I think we've got our roadmap, which provided a lot of clarity. We have our design goals, you have you should scenarios all. This should help increase our focus, and this also, this just helps any any newcomers come and contribute to. The effort really understand, what's going on which I also appreciate, because that whole the whole journey is important.

E

So, in closing that issue, do we feel that the it sounds like we're saying that.

E

I think that it might be good to capture somebody said at the beginning of this call.

E

This is not a point-to-point system we're specifying how to describe the events that are generated and I don't know if that is actually I mean it's in the design goals, but the design goals also talked about that these have to be used within a system where there's a consumer and now that maybe 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?

E

If somebody says a like any question, why aren't we calling this cloud messages? Hi.

C

I tend to think that the the current text that we have around scope, I've always said in 1:17 relative to sort of our guiding. Usually, scenarios I think sufficiently explains. What's going on, I, don't think we need to clarify anymore so.

H

The clock messages question came from me and it was in this discussion about topics. So I was just imagining this PR o95 goes through. Then you would have attributes for topic, subjects, I, think event ID times them, and if you replace the term event and these attribute names, then you would just have a message: header, not not nothing specific for event. So that was my concern. When I asked that question right.

C

But so that's a question on PR 95. Yes, it's early on to define your scope, so I don't live in a city! Talk about that right here! All right!.

H

What's fine with the goals here, I mean you know, states, that's events and everything all right. Super I.

E

Just I think that what we're proposing in this breakout session is that the usage scenarios, combined with the good design goals with these additional changes, will address the scope with thee with like, and maybe it might clarify things if we say in the roadmap that wherever this is sorry that.

E

We that this is that to refine that you know like.

F

I.

E

Don't.

B

Know I.

E

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 be fine, I, think it's part of the spec and part of the point. One milestone is to define the spec, so it works. I.

G

Think we need to be explicit that the scope is not prescriptive about those use cases and they're only there, as example, of how people might use cloud events did.

B

You put that at the top of the usage scenarios.

F

Sure we give it something like these. These are meant as kind of general guidelines.

B

A lot of comment there yeah.

E

I think using them is like sort of guiding principles for the design, but not meant to be prescriptive as the only use of cloud events so.

C

I would just ask if I three minutes left if someone's gonna recommend a change to this PR. Please suggest exact text. You want to see if it's more over.

H

I, don't.

C

Leave I know it's just just in general, if you, if there are other things, you'd like to see, add later whether it's this doc or another, one I just strongly recommend a follow on poor request to make those changes.

G

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 at least make that clear that it's not the intention of the spec to describe these cases for cloud events.

E

Clémence else also said that this could be. He didn't feel like this needed to be in the spec either. So we could put this in the About section, yeah.

C

I think I'm, a very first phone call. We talked about potentially a follow-up er that extracts this from the spec, but we wanted to get the text first and then forgot a place. No later I.

G

Mean it helps to get the same language and within the working group, even if, ultimately, the work is thrown away right or not included in the spec yeah.

E

Then becomes context kind of like we have the status for a while, and then we refine it mean.

I

So we are, we getting close, so I think that's the the last point I wanted to make to Austin. um 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 pull request right, whether it's 117 or 122? Let's decide right now and then.

B

Also, today,.

I

Yeah I completely agree, I was gonna, say 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 worried.

B

About how about like noon Doug's time Doug? Are you west goose one.

C

Minute, yes,.

I

Noon for everyone, who's on a same time, zone.

J

We.

G

Delete the PR all together, it would only take one minute just.

E

Alright I think you.

F

Everyone thank.

E

You everybody who.

F

Actually one last note: I wanted to make real quick 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.

H

Stress that.

F

We go right into the attributes after this because I'm just getting a lot of direct messages and emails. Oh I'm.

C

Very.

F

Anxious to do this, but I was going to suggest on.

C

The call is basically no discussion about this issue and just goes straight to basically a vote and then whatever PR is ready to go relative to attributes. That's the next on the agenda, so.

E

um So, yes and I really liked the suggestion that we do a collection of attributes together where they and they're related to each other and.

C

Sarah I think that's probably acceptable way to go, but the best way to have that discussion is file a PR with what you'd like to say and.

E

As I said yesterday, I will do so. Okay.

C

Cool, that's all I've asked I'm gonna be in nag about.

A

That one I in terms of process I did at Lawson's stand on to the attendees. For today, does someone take an action item to just write a couple of quick notes about what we discussed or direction look Sarah I? Don't.

C

Like them,.

E

Go.

C

For it, I can do it. If you want that's, not a few thanks.

E

Dyke yep.

C

Secretary, am I yes all right? Is there assuming people have until what 3 p.m. Eastern to get their new textual changes they want to say in there? Is there any reason to meet again on Monday, or are we basically assuming we're done? I? Think.

E

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 gonna propose I made a government's proposal ages ago and I'm gonna 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 that use cases making time box it.

E

Ok.

C

Does let you not think the governance every set the world allows plenty of times people to do that, but PR way, that's what you want it: okay, okay,.

E

Thank you thanks everyone, its critics. Everyone have a good weekend.

F

Yep I guess your.

C

Weekend, everyone.

F

You.
youtube image
From YouTube: CNCF Serverless WG Meeting - 2018-03-23

Description

Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.