 Excellent. Gotcha. Thank you. All right. Tim, are you there? Tim, are you able to talk to you about William? Hey William, was that Tim back there too? Yep, I'm here. Excellent. Thank you. All right. One more minute though. I'll get started three after the hour. Hines, are you there? Yes, I am. Cool. Hey Matt, how's it going? Present. Present. I'm alive. That's good enough for you. All right, three afters. Anybody I miss? I think I might have for everybody. All right, let's go in and get this show on the road. That's unusual. We don't have comments. All right, let's get started. Community time. All right, any community related topics people would like to bring up? Nope. Okay, cool. SDK work. We have not had a meeting, so I don't think there's anything to bring up there. Demo work. Good to see. So, actually, let me pick on somebody. Scott or the other Doug, anything you guys want to mention aside just from us making good progress? I guess, from my perspective, I'm looking for an update from you and Scott. I've parked out time on Friday to do some work on this, so I'm going to spend tomorrow working on that. Okay. Yeah, from my point of view, I was going to spend a good portion tomorrow and this weekend, we're working with the intern on getting the infrastructure for the demo set up so that hopefully by our Monday phone call, we should be in a state where everybody wants to participate and just follow a simple list of instructions to figure out what they actually need to code up. We do have, we've made some really good progress on the demo flow itself and what the events are going to look like flowing back and forth and so I guess that hopefully we should be ready to go and go ahead down on Monday. Okay. Let's see. Cook on EU planning. Nothing really big here to mention other than I did put together some template where I put together some Google Docs for the template for the slides. I know no one's had any time to actually work on the slides themselves, but if you are working on either the intro and deep dive or in the serverless working group session, the templates are there with the links here on the agenda. It's just basically the intro title page is more than anything else. So Kathy and I, Kathy, you and I need to work on the Practitioner Summit slide deck as well. I think I did put the slide deck for that. The template is out there as well. So anybody who wants to review our work for any of those four different slide decks here in the links, you can take a look at it as we start making progress, but as of right now, they should be basically blank. Let's see what else. Okay. Nothing about Cook on China, I don't believe since last time. I still have not started the slide deck for our yearly review. That's on May 7. I did ask for some time from the TOC, I believe on next week's phone call to get some clarity on what they meant by three independent end users. So hopefully that will help us decide whether we want to or can go forward with possibly moving to incubator status out of sandbox if we want to. But I figure we need to at least understand what the requirements are before we actually have that discussion. So hopefully we'll get that next week. All right, before we jump into PRs, any other high level topics people would like to bring up that I may have forgotten about. All right, cool. Moving forward then, Scott, you're up first with a hopefully relatively easy one. All right, would you like to talk to this one? I was just finding it difficult to search the text at master. I noticed there's some conflicting data that's happening. So I changed the version to 0.3 width so that it's clear that the version at master is the future version, not a back ported thing that's supported in P2. And we did talk about this briefly last week. We decided that rather than just sticking with just 0.3, we put something at the end to make it perfectly clear that it's just a work in progress. Scott made those changes. All right, any questions on this one seems fairly straightforward. Any objection to approving this one? All right. Thank you guys very much. Thank you, Scott, for that. I know there's been actually a confusion point for some people in the past. All right, next one. This one has been out there for a little while. Now, Kathy, this one, we made some edits based upon some of your suggestions in particular, I believe. I proposed some text and you're okay with a fair portion of it, but then you want that last little bit removed about ordering. And I believe, what was the gentleman's name? Who owns this one? Is it John or Jay? You know, Jay Roper. Left, added the text, but then left out that part that you were concerned about. So I'm hoping that this text right here addresses your concern without introducing the stuff that you're worried about. Yes, is this what you wrote? I believe so, yes. Okay, yeah. Thank you, Scott. Yeah. So I know that everybody's been paying attention to this. So let me give you guys just a second to, let me just see this. Yeah, the main parts right here are these two sections. I'll give you guys just a minute to look this over. But I think we have talked about this in the past and we're almost ready to go. And then Kathy had some last minute questions and concerns. And this is the paragraph that tried to address them for concerns more than anything else. I'll give you guys just a second to read that and come back up to speed. Okay, so just a reminder, this is just an extension. It's not part of the court. It's not being proposed for the core spec. Are there any questions on this or concerns? I think this is getting a great direction, but would still prefer some more examples or where there's some below. I don't believe there are examples as of right now. Yes, there were some pretty great examples discussed two weeks ago for this. Now that I said that I don't actually remember them anymore. Yeah, I think Clemens, I think Clemens had some really good examples. He was going to write up. Am I correct in assuming though that we could do those as a follow on PR? Oh, sure. And the reason I'm pushing a little is one, this one's been out there for a while and I feel a little guilty that we kept them on hold. Even though it was good discussions that had to happen, but I know that this is also a blocker for the Kafka transport. I know there's some people are very anxious to get that one in there. Well, does this really solve the Kafka transport issue? Because even with Kafka, you have no idea what partition it's going to put key data in. I'm not an expert in that space, but I believe they wanted to leverage this extension in their transport definition. This is literally the same unless you are writing your custom producer that manually sets the partition. This is literally the thing you give to Kafka to do the partitioning. So yeah, this solves the problem. But Kafka does not automatically use a partition. It determines the partition based on a hash of certain data and it automatically in the client will put it into the correct Kafka partition. Yes. Sorry, go on. No, no, sorry. Yeah, yeah, sure. So basically in Kafka, the client decides the partition, but it's unless you're doing something really weird. You use murmur to hashing on the key of the message and the cloud event spec has no place for the key of the message, which is a important primitive in Kafka. So you have the key and the message and the hash is always on the whole key, the binary data of the key. So this is the binary data that you would use for the key in Kafka. And this would decide the partition based on the hash of this key. Is that answer your question? No, but I don't think we need to go into this early, but again, the cash is created by Kafka under the covers. So, you know, if you send a cloud events and you basically pass that to Kafka, Kafka would have to still manually put a key into the data. So that's what they're talking about. That's fine. It's a separate key, but it wouldn't be the key, the key hashing that Kafka uses that you put it in a partition. So you could actually use any key doesn't have to be specifically a partition key. I guess I'm saying that's just the name of the field or don't understand the problem. Well, I think it's redundant because if I was doing a Kafka binding, which doesn't exist yet, I would use something like a correlation ID or probably a correlation ID in the cloud events message. And then when I pushed that into a Kafka binding, I would use the correlation ID as the Kafka key, which would automatically get hashed and put into the correct partition. So I could. So this is just a redundant version of perhaps another key like correlation ID that already exists. Well, yes and no, what you're talking about is a semantic ID or key that would be used for partitioning. But the problem is that partitioning is a process defined. It's process defined. So you might have different hops that need to partition based on different correlation correlation IDs. Correlation ID is a very generic field name. It doesn't really imply anything. You could have many of those for an event. The point of the partition key extension here as I've understood it is to create the canonical plays for that key. So if you knew that you wanted to use correlation ID X as your Kafka key, you would put that here for your hop. But when you pass that event forward, some other consumer or some other process might want to partition it differently based on another correlation ID. Then they would modify this field as the extension spec says for their use case. That's the, it is redundant, but it's redundant intentionally because it makes it unambiguous what you actually want to be the partition key. Otherwise the binding actually can't know or it would need to be a specific parameter of the binding or something. I don't even know, but these was all of those options were discussed beforehand. For example, Clemens had that idea that you would use a path to get the Kafka message key from the cloud event. But instead it was decided to use something that already exists. So that is extensions and attributes there. And since we don't have a decision that extension field should be immutable, this seemed like the proper way to do partition key because you, it's not set in stone. You want to change it between hops, most likely. Okay, Timmy. But a correlation should be immutable, right? It's a correlation. No, it should not. So Clemens had a great example here where if you take in a huge amount of messages and then you partition them and you give each partition to a downstream consumer. And that downstream consumer then again needs to partition it. If your partition key is immutable, the downstream consumer actually cannot partition it because they already were in the same partition, which means the key hash to the same bucket. So the downstream consumer actually has no way of partitioning their set of data, which they read from one partition upstream, because their keys are all hashed to the same bucket. So that is why it's not possible in something like Kafka to have an immutable key if you actually want to create complex pipelines. Well, that's the point though. In Kafka, you would use a stream processor. It would be an immutable key because everything you put into Kafka is immutable once it's into Kafka. It's immutable. It's not immutable between you and the next hop. They can modify their message when they put it into Kafka again after they've processed it. The point here is you wouldn't modify this like in place. You would process your stuff, put it into Kafka. The next consumer will process their stuff and their results would have a different partition key, which would then repartition the resulting data. There's just simply no way an immutable key can work for the whole pipeline. Well, it can because when I do my stream processor, it goes to another topic. That topic will have different partitions and it would then use that same partition key to partition it again in that second topic. If you use the same key and you have, say, same partitions in both topics, your second topic will have the exact same partitioning as your first one. The murmur to hashing is intentionally deterministic. What you're saying doesn't actually repartition the data. It just puts it again in a different topic in the same partitions. I think the confusing repartitioning of Kafka, which is adding partitions to the same topic versus stream processing against the immutable messages in one topic. I think we're going off on a tangent. We need to have a side discussion. Hold on just a sec. This is a problem we have all the time in event processing. When you want to send events somewhere and they get very high volume, you have to use sharding because that's the only known way to have arbitrary high volumes. The conventional technique we use is not to specify our partition key literally, but to specify a JSON path or equivalent saying, for each event, here's how you pull out the partition key. That seems to work really well in practice. I know in our messaging products, we do the partition keys when I need to partition, completely transparent to the payloads. That works fine as well. We partition on other parameters, which is against the payload and a bunch of other things. This is very Kafka-ish. I'm saying with Kafka, it would be redundant. It is immutable if you are using an example of repartitioning that is a stream processing in Kafka, which, again, if you want to use a separate key, it would be like the equivalent of changing a correlation ID, which you probably would not be allowed to do as far as a lot of these business apps. Without this extension, how would you specify that? Would you specify that key? You say different parameter. How would you define for the Kafka binding your key? Well, when you do the binding in Kafka, you would be able to choose one of the other keys that are already there, which would probably be the correlation ID, because you want to end correlation. As I said, that was an idea by Clemens, which was disregarded in favor of this extension, which is the same thing in a different form. You would set whatever your wanted correlation ID. If you never want to change it, that's fine. Or if you want to change it as you just said, that's fine as well. But this extension is where you would set that key. I don't understand the problem. It's not a problem. You can add. I'm just saying it's redundant, and you want to keep adding redundant fields, especially if it's targeted towards only Kafka. And I believe it can be done without adding this field in Kafka itself as well. So I'm just trying to cut back adding extensions that may be redundant. Or redundant for only one binding. So I want to make sure I understand what you say redundant to me. Redundant because this data someplace else, in particular. In a correlation ID or a combination of correlation ID and stream ID. And because there is no current Kafka binding, it's kind of, you know, you're adding things for another potential spec that doesn't exist, which is the Kafka binding. Right. But I, right. But I think if I remember correctly, I believe that, oh, that, that, that spec does exist in the sense that it's a PR. And I think they, rather than wanting to create their own extension, just for them, they thought this was, this was a generic enough thing that maybe it should be a standalone extension. Indeed. This is a blocker for the Kafka spec. So I don't really understand your argument. Well, again, depending on how you spec out, even if I did a, if I wrote the Kafka binding, since I could use the keys as full objects, rather than single strings or fields, I would actually do the binding where I would allow them to specify attributes in the header. Or it could be attributes even right from the payload that I would create before I actually wrote the record to Kafka. So adding a separate field for partition I think is redundant. There's enough in the current spec to be able to do all the key stuff you need for Kafka. For partition. There's no generic way of specifying what that data is though. That's what this extension is trying to solve. Hold on a sec. What you want to do is for, have specific ways in each binding that we use a partitioning key to specify it from inside the event if I understand correctly. Yeah. So Christoph has his hand up and let him jump in every second. Yeah. So what I gathered from the discussion that the other people had was that for them to be able to put it into a Kafka partition, they have to have a way of letting an event producer decide in which partition it should go. So this is the way for the event producer to tell whatever Kafka middle where there is, how it should be partitioned. I'm not sure if like, because the Kafka binding should work for all cloud events, also for cloud events that don't have a partition key. So they probably have to have a fallback in the end. I don't know what that will look like. What I think what we should get at is that this is an optional thing that an event producer can add. So that then a Kafka or another messaging protocol that wants to partition can work with. We should kind of see that it is an optional thing. Yeah. It's only optional. It is just an extension. So Heinz, I'm trying to figure out. Go ahead, Scott. Yeah. I don't think you want the producer to choose the partition key because they're going to choose a bad value. You want the middleware to be able to specify what the key is. And I don't think the consumer really cares at the end because it shouldn't need to know where the event came from, from which partition. Is that right or is that wrong? It depends on the use case. I made the same point actually because I'm like, I write really, if you write a software service, then you don't really know what your consumers will, what if you write an event producer in your own ecosystem, then it's very likely that you have the knowledge of your consumers. So again, I think it's optional. So if it's a way for them to move forward with the Kafka binding, then that's kind of okay for me. But they can just use this binding or they can use this key as an extension and not have it be in the spec because it's part of Kafka. The Kafka acceptance thing should know that this extension exists and the producer... You cut out there for a second, Scott. Yeah, I got zoomed. You want to finish your sentence? I don't think that the original cloud event producer needs to care about what partition key is going to be sent downstream. It seems to be an individual hop. Doug highlighted the part of the text. He's highlighting it again, which exactly tries to convey that message. I don't understand why you would not spec this as an extension and why would you leave it to the individual transports because if you have a Kinesis transport and a Kafka transport, they would work exactly the same way with this extension. I don't see a reason why you would leave it to the individual bindings to define an unspecced extension when you can just do it generically. But that's the point. The binding in Kafka, if I had the binding, I wouldn't want the cloud event to force me to use an extension, which is only a single string because I may want to define in that binding that I'm using parts of the payload and maybe other header properties to configure an object for the key by telling them they can only use this one optional value as the string. I think it's going to be the service when they have a Kafka binding to limit them on what they can actually use for the Kafka key. Are you saying that as a producer or consumer? It's always for the producer because the consumer is going to bind to all the partitions and pull it out or you will use a stream processor to bind to all the partitions, pull it out and write it to another topic that then just has those key values. Right, so my assumption, I think Topini covered my wrong here, but my assumption was that the producer would use whatever values they need to to decide what the purchasing key is going to be and then they would stick it into this field so that the consumer could then use it and wouldn't have to do, in essence, the exact same logic that the producer just did. If you're building an in-house system, probably yes, but not necessarily. The producer might not even define this key at all if they don't know it's going into Kafka and then some middle word that's actually putting it into Kafka will define it because they know how it should be partitioned. I now understand how it's what you're going after. You're going after the fact that Kafka already has a key that is used. The problem is cloud events are singular objects. They are not split as a key and as a message as in Kafka. So you need to somehow define that key. I don't believe it's a disservice to generalize how that key is defined. You can still put any data you want in here. You can encode your objects, your headers, whatever you want here. It's still binary data for Kafka. Kafka handles everything as a binary data. So this is just a way to set the key in a cloud event which doesn't naturally have a separate key to partition on. Yeah, exactly. And this is where the binding in Kafka. I would then define that of how I'm going to create the key. I don't want to have it limited to an optional field. Right? No, I don't understand or I don't grasp the difference you're after. I just... Well, I will change and try a different use case. If you do the use case of building, for example, a Kafka connector. So let's say I've done a binding of... Let's say I'm using just some other messaging middleware. I've written a Kafka connector and I want to push that cloud event message as part of routing into Kafka for some processing. In that connector, I determine what the key is going to be from that third-party messaging where I do that part of the connector, which would be the equivalent in the cloud event in the actual binding of the Kafka binding against the spec. So that would be against data that I've already received, either header data. It could be payload data. And I would then determine how I'm going to partition the keys for writing to Kafka, which will automatically put it into the correct partition. There's no real... You're limiting yourself with an optional field to build that binding. I think we just simply disagree with them because I don't think this limits you in any way. You have to encode your data as a string, which, okay, yeah, not nice if you use the normal Kafka clients, but it's in the name of generalization. I don't think I will be able to convince you that you don't lose something here if you do think you lose something here, because to me it's just two different ways of defining the key. It will still be this key in Kafka. It will be partitioned based on this key. Kafka will automatically choose the partition based on this key. It's just encoded as a string instead of as any binary data you want. Actually, it is any binary data you want as it's a string. I don't grasp the huge difference you're after here. I'm just saying it has two issues. One, it's either redundant because just like with a connector, for example, which would be similar to building the binding, protocol binding, you would be using data that already exists in the cloud events, either in the payload or as part of the header to determine the key, the same thing you do when you do a connector into Kafka. No other messaging has a concept of the key when you're writing a source connector for Kafka. Therefore, you do the exact same thing. You look at the payload and header data that you've just received and you determine then how I'm going to create the key, which is generally an object. It's not one field. It's usually a combination of things to build the object as a key, which I then pass to Kafka, which will automatically then figure out the hash and put it into the correct partition automatically. So it either is going to be restrictive if you expect them to use it or it's redundant because you're going to use other data anyway, just like with a connector. So Scott, do you have your hand up? Yeah, my question is how does the producer use Kafka or whatever if they don't understand that they're going to be sending to Kafka? If the original message has no partition key, how does that get injected into Kafka? That's the same as you would use with a Kafka connector. You would then look at that payload and you would look at header data and determine what are unique attributes that I want to group all the data to make sure it's all ordered against that group's data. And it's either a single field like a correlation ID or it's a combination of payload and header data where I would create an object and when I actually now create the Kafka records to write it to Kafka, I would add the payload data that would probably be right from the full cloud events payload and header, as well as now the key data that I generated to create the key when I wrote the record. So that's exactly what you do with a Kafka connector as well in and out of any other third-party system. So it sounds like the payload doesn't get modified on the injection? No. No, there's no modification of the payload whatsoever. You're just adding a key because again Kafka are just name value pairs where the key is the name and the value is the payload. So Topini, your hand was going up there for a minute. Did you want to say something? Yes. I'm sorry to keep repeating myself but there is no difference between you specifying a group of attributes as an object and you specifying a group of attributes encoded into a string because they are both binary data that Kafka will use for the hash. There is no technical difference between those two things. Between you choosing in a Kafka connector a group of attributes and encoding them as an object into the key and you encoding those same attributes into this field as a string. Kafka will not care. It handles it all as binary data. What I do understand from your objections is the fact that this will indeed duplicate the key into the message if I understand correctly how this extension work. Unfortunate in my opinion. Some people gave examples where that would be useful because on the consumer side you wouldn't get the key from Kafka. You would only get the cloud events and this then would specify what was used as the partition key so you could even reuse it if you want. I know. I simply disagree with your problems with this. Sorry. It's been a good discussion even though most of it's over my head but I'm trying to figure out Heinz. Are you suggesting that we should not adopt this or just that it seems like it's unnecessary because it's duplicate information? I believe it's unnecessary information because everything you send to Kafka either through a stream processor, a connector because really what you're doing is some kind of integration which is really what we're discussing. The integration point either the stream processor, the connector or in this case which would be the Kafka binding which does not exist yet. It does not assume that you have created a key for Kafka inside of it. Do you do it before you pass it to the Kafka environment or after? I'm saying that you would always do this after just like when you wrote a connector. You're not going to tell the upstream third party system to say I need you to calculate this partition key for me so that when I pass it to Kafka it can use that partition key. You would do that in the binding layer for all the cloud event data. Now I need to key this data because I need to have it guaranteed to be in order process in Kafka. I would then calculate the key when I write that record from that third party system into Kafka. So why would you want to calculate a Kafka key before you send it, put it in cloud events? It is so tightly coupled and duplicating what you're going to do in the other side anyway. Okay, Kristoff, your hand went up first. I think we're getting to actually the point that the offers of this try to make and I think their point is that I want to write a binding that is just standard code and that you don't modify at all. So if you... And it works like generically across events that I have never seen. So in which in the case that Heinz suggests means I always have to go in, I have to understand I get events of this shape, blah, blah, blah. I have to extract my key and so on. What they want to do is they want to write something that is the same for any type of event and then that changes the way I think. Does it make sense what I'm trying to say? No, totally. Again, do I want to create the key before I put it into the event to make sure it works and make it easier to write a Kafka binding or do I keep it completely separate where it has no knowledge that Kafka is going to be involved in the cloud event and then have to have some kind of configuration or some kind of interface to allow this to work in a Kafka binding? Yeah, exactly. So I try to make exactly this... Sorry, go ahead. I try to make exactly the same point to the offers that there will definitely be events where they cannot assume that the producer made or added a partition key and then he will always have to at least have some fallback. But I think... Yeah, I think my personal opinion is that we should look at this together with the binding that they propose and then if we as a group think it doesn't make sense to have like a generic binding, we should always assume that a binding when Kafka comes with a configuration that would also be something but it needs to be discussed in the context of the proposed Kafka binding. I agree. So Tapini, your hands up. I disagree. Those two things are not exclusive. This extension specifically states that you can redefine the partition key. So that is the point where you define it after you get the event hines. It's not producer only... only producer defined. This says specifically that you can change it. In cases where the cloud event is delivered to an event consumer via multiple hops it is possible that the value of this attribute might change. That is the specific part that says you are not tied to the partition key set by the producer. That's one problem that came up. Christoph, for your thing, if one does not exist I would assume most producer wouldn't set this key. That's fine. If you don't have a key it will go to a random partition in round-dropping fashion. If you know you're going to put your messages into Kafka this is the point where you would say where you would define that key how you want them to be ordered. I don't actually... I understand the concerns. I think it's a problem with the wording that this doesn't convey how it should be used. I think Scott has a good point in the chat that maybe this shouldn't be top-level extension but something else. We just don't have that something else which is why I think this was defined as an extension so the Kafka binding could get moving because we also didn't want to do a Kafka binding specific way of specifying the key. That's what Clemens actually suggested weeks ago but somehow I wasn't part of that conversation. That was disregarded. I don't remember why. I think we need to wrap this one up at least for this phone call. So, Heinz, can I get you to take an action item here and put down your concerns into a comment into this PR because it seems very odd to me that the authors of the Kafka spec feel like they're blocked by not having this and so the fact that they consider it is sort of required bit of information in order to make forward progress says that something is seriously needs to be discussed. It's the fact that you need the key for the message and there's simply no way as envisioned now to set that key for the Kafka message to ensure your ordering. They didn't want to do a binding specific thing. Is the key needed for the consumer? No, it's needed to actually put that message into the correct partition in Kafka so when you are putting it into Kafka you need to know the key. There's currently no way to set that key without the Kafka binding creating its own special way of doing it and I don't think that's the correct way to do it because this is not a Kafka specific thing so that is the major use case we're talking about now. Kinesis is a good second example. They have the same model. I think the quality of this debate would be greatly improved by having some concrete examples to look at. Yeah, that's what I would prefer before I start making comments because when we throw out things like well it's for routing, well even in Kafka if you're routing it isn't moodle to put it into the first topic. Routing is all done in Kafka using stream processors and you can create whatever key you want it has nothing to do with the original publisher as the original cloud event. Okay, so I think I'm hearing a couple of things. One is some examples, I think Scott you call the use cases that's fine. We can ask for those but Kines, can you also add some comments to the PR itself explaining your your concerns? I'd want to see if we can wrap up this conversation in relatively short order over the next week or two. As long as the next week unfortunately I'm gone the whole week so if you don't mind till the week after then yeah that's no problem. Well, can you at least add your comments today to at least get the conversation going? Well considering on holidays today and I've missed the last two so I think I better come in just do all. I could but then you'll have to come live in your garage because my wife will kill me. That I understand, okay. Well, you can add comments. Kristoffer, Tapini do you guys understand Heinz's concerns well enough to maybe put a comment to at least get some of the conversations going in the meantime? Well, I do not want to describe Heinz's concerns because I think I have some kind of grasp of them but I don't understand specifics or I don't understand the specific concerns so I do not want to speak for him. Which I appreciate. But I was just going to say it's very simple. I believe it's redundant and I believe like every other way of injecting published data from third party from anything into Kafka the key is always generated at the binding or the connector or at the stream level. It is not done necessarily at the external source which is the architecture for things like Kafka connectors which is a standard way to get the data into that. Agreed, I think you simply this extension does not define it as something defined by an external source. It specifically says you can do that at the point where you are putting into Kafka I think that's where we just disagree on how that should be done. Right, okay so I'm going to call time here because I think Kristoff you had the exact same thought I did I just put into the meeting minutes. What I'm going to do here is two things. One is ask the authors to give some concrete examples and use cases for this and two ask them to watch the recording of this and then they can comment on that back in the PR itself because I think I think the author of this is technically in Australia so it's going to be really difficult for him to join this phone call I believe. So let's see if we can make progress through those two avenues, okay. Excellent discussion I think very lively which is unusual for our phone calls so that was good. Okay so let's talk about Alan's PR here. So overall I don't believe Alan's on the call right now Alan's PR here once it loads is he wants to add some text to basically clarify that source plus ID uniquely identifies any event and in particular you can use that for dedupe or something like that if necessary. I believe on last week's call we talked about this a little and in particular Scott I know you weren't there but we tried to bring up the idea of including type as part of the as part of the uniqueness aspect to it and there wasn't a whole lot of support for including type in there but I wanted to get your I want to give you the opportunity to speak to that if you wanted to without before we just decided without you on the call. So did you want to talk to that because I know you were advocate for it. Yeah it really does need type because ID is something that is that can come from the originator of the event the producer the source is coming from the producer but type comes from the adapter so there's no way to understand that the particular event comes from a particular adapter if it doesn't have the type because type gets to be accustomed to the adapter not the producer I think you may need to elaborate a little what you mean by adapter because that sounds like an implantation detail. If a particular producer is not a cloud event and it tells you a bunch of data so like we had this case of a database commit ID right online 250 you can adapt that into a cloud event and the source and the ID will be exactly the same for two different implementations of an adapter to a cloud event but the type should be different because the type comes from the adapters implementation so the only way you know that that event is a dedu is if you also include the adapters ID which is the type. Okay Chris stop your hands up. Can you what I don't understand is why would you have the same event come into your system with two different adapters. I have the prod adapter and the beta adapter potentially or I have two different implementations of a similar adapter because I'm evaluating. So my hands up next. So it seems to me that Scott the adapter is going to blindly take some ID that it got from the system that actually produced the event or generated the event. It's that adapter job to manipulate that ID in some way before it uses it as a cloud event ID and if that means adding some unique thing to it some additional unique thing to it like maybe the type maybe some other identifier and concatenate it whatever it seems like it's that adapter's job to make the cloud event ID unique if it was trying to use some previous field that isn't unique unto itself then it was making a bad choice to begin with. Does that make any sense? So do we lose Scott? No I'm just processing. Okay yeah because my point is that just because you want to use an ID that was given to you doesn't mean you maybe can use that ID because it may not be necessarily unique but this field has to be unique so you need to make it unique as that adapter. But the ID is unique for that individual producer so it's still conformant to the spec but you can still have two producers that are producing the exact same event according to this definition of unique and you won't be able to understand if it's from producer A or producer B because their upstream source of truth is giving them the same data. My understanding drifted because when I think of source I think of source as uniquely identifying a producer. Right. In that case, both of these two adapters would have unique IDs for different sources. They are not the source of the event. They are just an adapter. They're taking a non cloud event payload and turning it into a cloud event payload. That's my question about my understanding. I'm trying to crack what you said there, Eric. My understanding is that source is effectively a unique ID of the producer of the event rather than some data like a database name or something like that that could then be used as the source or by multiple producers. Source is just a URI of the originating entity that's making the event. So now actually we have to add subject. So source is the generic potentially bucket name. Source is that the bucket object would be the subject. Scott, you went on mute again. Zoom keeps doing something funny. Okay, try again. Well, regardless, I think because we now added subjects, we have to add subject here too. So it becomes a four pole of source subject ID and type. That's how you know it's unique. I guess I'm still confused though, Scott. It seems to me that you're trying to assume that the ID that's given to this adapter it can't be changed in some way to be made unique unto itself and that this ID has some semantic meaning outside of just providing uniqueness from a cloud event perspective. Am I correct in that assumption? How would you know as a consumer of that event how to unmangle the ID back to the database commit ID if it goes to the producer? That's my point. He shouldn't. This ID is not meant to be anything other than uniquely identified this cloud event from other cloud events. It's not supposed to have a semantic meaning like a database commit ID. You can use that ID if that ID happens to be globally unique but it's not meant to convey oh, consumer use this field for the commit ID because that's not what it's there for. There's some other field for that. I still think that example should be removed because it causes so much confusion. We tried to remove it in some other PR. Yes. Because it implies there's additional semantics aside from just cloud event uniqueness. So if you do that then you don't know how to deduce the data unless you also look at the payload and now you can't do any you don't understand how to deliver once events. Well, I don't think that's true. It depends on whether you want to dedupe from a cloud event perspective or dedupe from some sort of semantic meaning of the event itself perspective from a cloud event perspective of resending the exact same cloud event I think you can do it with this ID. But if you want to have some semantic smarts and somehow do deduping from a data perspective that's outside the scope for us. Does that make any sense, Scott? Yeah, I just don't really agree with that sentiment. I think there is something interesting here but we also need additional data to understand if the event is deduced or not. Well, the problem I see though is if you head down the path where I think you're headed where there's additional semantic meaning behind this ID how the heck are we ever going to define what that semantic meaning is? Because it's going to mean different things to different people. Right? The idea of the cloud event is we get to choose what this ID means. But this meaning is going to change depending on the use case. Yeah, yeah, that's right. But I think if you force the ID to be modified by adapters that turn it into a cloud event so that it can play in other ecosystems, you lose the original intent of the event. But I guess I just don't understand. I would seem to me that if you actually want to have someone do something smart with someone like the database commit ID you would create an attribute called database commit ID. But everybody perfectly understands what this thing means and how it's meant to be used. This ID what you're suggesting is it can have multiple purposes not just uniquely identify cloud events and stream of cloud events to convey some other semantic meaning that's defined at the application level. And I don't see how you can guarantee that those two meanings won't conflict for all time. Well then we should change the cloud event attribute from ID to transaction ID or something because if it's just the GWID that we give it as an ingestion key then I'm not sure what its purpose is anymore. I think that that is its purpose basically is simply provide a unique ID for this cloud event so you can differentiate it from all of the cloud events. But then you're sending multiple cloud events that de-dupe on the transport but are the exact same content. You're sending the same event multiple times because they have different IDs for cloud event ID but they're exactly the same content for the payload. And now you've pushed the exercise of de-dupe to the consumer instead of the transport. Why would they have the same content? Because they just replayed all the database commits. But I think if you're asking cloud events to de-dupe that I think you're asking it to do too much because now it has to understand the semantics of the application. I don't really agree with that. I think this is what it's for. Okay. I don't know this one. Another one needs to take offline. Scott, can you do me a favor? In that document that we have where is it? In this document right here can you add some comments in there explaining exactly what your definition of the cloud event ID would you think the definition of cloud event ID should be? I already did. Okay. I didn't see that. De-dupe. Speedy today. So where is your exact definition you'd like it to be? We can talk offline. It's in the climate. Okay. We'll talk online. We'll try to continue this through this document. I think that's probably the biggest difference of opinion is what is the ID meant to be used and what is its semantic definition. We need to get some clarity on what different people want it to be. Yeah. Only three minutes left. I don't think we have time to jump into another issue. Especially since the next one is the big one about the code issue. What I will say is this though. We have technically a phone call scheduled right after this for the Kupkan EU session. It may be a very short call but for those of you guys who are planning on doing one of the three different or four different sessions at Kupkan EU please join that call as we can get some syncing going there. In terms of people on the call I believe I have everybody except Mehmet. Are you there? Mehmet? Okay. Did I miss anybody else on the call relative to attendance? Yeah, this is Maroon. Hi, this is Mehmet. Hey Mehmet. I got you. And Maroon, I got you. Cool. Anybody else? Okay. Cool. In that case, thank you guys very much. And we'll talk again next week. Oh wait. Javier, are you there? Hi. Excellent. Okay. Just made it then. Better late than never. Okay. Thank you guys. We'll talk next week. Oh, crap. Hines left. He's on vacation. I forgot to mention a few problems with defining it in binding and I wrote them in the chat but I guess I have to transfer those to the PR now. Probably. I'll be really great because I want Mr. I don't get to be lazy. Actually, I'm trying to copy the chat because I missed most of the conversation. So hold on a minute. Let's see if I can do this. It's funny how such a simple thing can be so complicated. It's actually a binary field within Kafka. It's just binary data that is used to partition something. It's funny how that can be so hard. Sometimes it's simple things aren't quite so simple. All right. Well, it's not time yet. Let's give another minute or so. I'll get it organized here. Doug, I delete the private messages. There's a phone number there and that can be considered private. Oh crap. Sorry. Private. Private. Where are the other private ones? Is that it? Oh, thank you. Was there another one in there? Actually, I guess I could just search for the word private. I want to also point out that you're still recording and that phone number will be visible in the recording. Damn. I will talk to Solace if he can get that fixed. Let me stop recording for a second or at least stop sharing. Where was that phone number? I didn't see that. Was it in the beginning? Actually, no, that's okay because that actually shows up in the zoom anyway. It's not like he was giving me his phone number to call him or anything. It just shows up in the zoom and I think that might show up in the recording by default. What is it? It might. I don't know. Well, let me put it this way. I actually said that phone number. I believe at the very beginning of the phone call. Asking who it was. Either way, we're screwed. So. Anyway. Whoops, wrong one. Let's try this again. Okay. Now that I've completely messed everything up, let's see. Uh-oh. What do I do now? No. I'm trying to figure out how I get... I'm on a different computer than usual so I'm figuring out how to get all of these comments I met in the chat to the PR on another computer. Well, you can... They're in the Google Doc now. I did put them there. Oh, great. Thank you. Yeah, that's right. They were complaining that I copy and pasted into the end of the agenda. Yeah. Okay. Hold on a minute. Thank you and sorry for using up all the time arguing about one issue. No, it's a good discussion. It's just, you know, it's unfortunate because I know everybody's really busy and this is the kind of discussion that you'd like to have through the PR and stuff. But of course, that's not necessarily the best way to have a conversation and we tried to have phone calls, but then the time's just gone away. This is the kind of way it has to play out sometimes, but it's okay. We'll eventually get there. Yeah, sure. Let's see. Thank you. Bye. Okay. Bye. All right. So let's see where are we. Okay. So Dan said he's not going to be able to make it. Boom. Let's see. So Scott, you're still on the call. Good. Okay. So... Kind of been a bad spot, though. There was a fire alarm and I'm in a cafe with like 3,000 other people. So, slightly noisy. Actually, it doesn't sound that bad to be honest. I don't hear too much background noise. That's not too bad. Okay. I don't actually think we have a whole lot to talk about because I don't think anybody's gone through the process of actually starting to fill out the charts. So, but I did want to ask a couple of questions. So if Scott... I'm sorry. If Dan can't make it, is there somebody else who would like to fill his spot? I believe he was going to be mainly talking about the introduction stuff. Who we are, scope of the spec and stuff like that. I mean, if we don't have any volunteers, I'd be happy to do it, but I want to think of other people a chance if they really want to because I've already done this. I think one or two different times already. So, do we have any volunteers to fill Dan's spot? Okay. If not, I'll sign up for that one. I don't mind doing it. So then, Scott, I'll take care of the intro stuff and then you can leave it on with the more advanced, cooler stuff like the SDKs and everything else. And then if we have time, the demo and stuff like that. Sound good, Scott? Sounds great. Okay. Perfect. Okay. The deep dive session. Let's see. That is Vlad and Clemens. I believe... Comments and concerns and questions. Okay. Go for it. Hello. Okay. I'm going to start the deployment pipeline with exceptions. But that is very, very closely... It's basically messaging that eventing. That's what I've been looking in the last week, or last two weeks. Time. And I'm not sure where to go from here. Like it could be mostly eventing to... In my initial plan overview idea, I had a UI that would just have a list of commits or versions you want to deploy and send the cloud event to SNS, SQS, whatever. And then that message would be parsed. But it's kind of messaging. I'm imagining I could easily tie this up to GitHub events to do everything on a commit or per build basis. But that feels like it's going to be a bit too long. So I don't know exactly where to go from here. But again, I haven't spent that much time on it. I times wanted this weekend for this. So... Any pointers? Any preferences? Anybody have any comments on that? To give some more background if it helps. The idea is that I'm working with a client right now who has an app that is very much even driven and scaling and all that. And it would be an absolute perfect use case for serverless. But right now they're doing containers and that works. They're also not being a startup that's only now starting to mature. There aren't a lot of solter best practices to put it nicer. Like no feature flagging, no observability, no AB testing, no all of that. And the way I've seen serverless use is most of the use cases fall into buckets. The first one being new startups, they do serverless because they want to optimize their cost. The second one is companies that are bigger and start playing with serverless to learn more to experiment and usually through internal projects like CI CD pipelines. And the plan was to they're significantly starting to work into automation and automated deploys and proper continuous deployment and stuff like that. I started working on it. I had to send tiny messages between different lambda functions or stuff like that. And we use the honeycomb for tracing and for eventing observability and all that. And I basically started designing a JSON that was heavily resembling cloud events. Like, okay, cloud events. It's boring. If you have to send something over the wire, you can use it. That was the use case and where the idea came from. But it's still kind of messaging. So I don't know. I just want to make sure, right? What's the name of the company you're working with on that? Oh, it's okay. It's a media company. They're doing video transcos in the cloud. Instead of a movie taking a couple hours to be transcode, the format it takes a couple minutes. All right. I don't know. The only thing I was going to say was we're going to work kind of this weekend anyway. Would it make sense for you to write up what you were thinking in more detail? That way people can read it offline and comment on that. Yeah, that was the plan. Yeah, that way Clemens in particular could take a look at it. Yeah. And how long should this take? What's the time slot for this? Well, we have 35 minutes. Okay, so I might be 50-50 between me and Clemens. I would assume so. Yeah, maybe we have 15 minutes each with 5 minutes for questions kind of a thing. I would think. Okay, so 15 minutes. Okay. Okay. And you're all fine with me saying, hey, cloud events are here. They're boring. Use them everywhere. I don't want to have cloud events to be the focus. I want it to be that you need to get data from a point to another. You might as well use cloud events because it's supported, it's growing, it's being used but it's starting to be native to different stacks like how Microsoft has direct cloud event integration. Is there a way for you to position it as cloud events either made your life a little bit easier or just makes life simpler at some point? Okay. Yeah, definitely. Versioning was the main thing. As soon as I had to do tracing, I had to do HTTP header, deserializing and serializing and all of that and that's already done by cloud events and by the cloud events SDKs and I would have just cobbled badly created JSON with some version pack and it would have been a lot of internal effort when I can just use cloud events. Right. That's an important thing. It's here, user. Yeah, I mean, I think boring infrastructure but helps you get your job done is fine. I mean, that's what they talk about from containers too, right, boring infrastructure. So, yeah. Okay. I'm open to many other concerns or ideas or suggestions. Yeah, I would recommend writing it down so that people like Clements could take a look at it because since you're going to be talking with him, you don't want to have him basically shoot down everything you just said because he's going to talk about this ain't doing great. Yeah. Yeah. Okay. Okay, that sounds good. I'll talk to you later. Okay. Okay. Okay. Create some diagrams and design doc this weekend. I tried to do this for this week but I couldn't squeeze it in. Sorry. Okay, that's fine. Okay, anything else people want to bring up relative to the deep dive session? One thing we do need to figure out is where we actually do the demo because we have it both as question marks in the intro and deep dive. So, at some point we need to figure out which session we'll actually talk about it or do the demo there. If you think 15 minutes is going to be pushing it for you Vlad and I know Clements can easily fill up 15 minutes, we may want to put that into the intro session then. So, Scott, keep that in mind as we go forward because I have to keep my stuff really, really short. If we take the demo and assume the demo is going to be five minutes kind of a thing then the rest of the time can be used for your stuff, Scott. Anyway, something to think about as we go forward. Yeah, I'm thinking of having a super short demo a couple minutes going through it and then going into how it's implemented and stuff. So, I'd rather have the demo in not in the deep dive so more people see it and in the deep dive I would assume like previous knowledge and go directly hi, this is CloudEvent, this is the extension you're assuming people already know what's the extension or what CloudEvent is as not to repeat all that. Yeah, I think that makes a lot more sense. So, let's push for it to happen up here in the intro and we'll see how it goes. So, let's do this. Okay. Doug, can I just bring up one thing? We had talked about potentially having the the lead of the airport consortia the ACRES ACI participate in some way and they they can't physically be there but they could be there virtually. I don't know if that's what you would even be able to support but the key guy is in Canada and he wouldn't be able to fly all the way up there for that that he could participate remotely in some way. Interesting. Okay, let's talk about that offline because one of the things you can never really count on are the networks at conferences. So, let's talk about that because worst case scenario if maybe he wants to do like a couple minute recording that we could show that explains why this is useful to him in his particular industry that might be useful right there. That seems like the best approach. Yeah, we could talk about that one but we could probably make it work. Okay. Excellent. Thank you. All right, finally the serverless session 85 minutes. Chad told me he will not be able to make it for that. I believe he was going to give a very brief state of serverless overview. Is there somebody who would like to volunteer to cover his spot on that? Just to refresh your memory, I believe the intent here was we were going to have a couple of quick little presentations like Chad was going to say, you know, what's chain and serverless? I believe what was it? Kristoff was going to give a quick little demo. Jude was going to talk a little bit as well and then after that we're going to lead into more of a bird of a feather type of session to interact with the audience to see where their pain points are, where they might want us to go from a serverless working group perspective in terms of what to work on next kind of thing. So these are all pretty much very short little intro things. Is there somebody who would like to volunteer to do the state of serverless since Chad can't make it? I could do that. Okay, because I was going to do it if no one else wants to but if you're volunteering go for it. Okay. Thank you, Scott. Okay, cool. Okay. In that case, I think at some point we probably need to just come up with a list of questions to ask the audience to prompt that birds of feather discussion but obviously we can wait until later do that. Is there anything relative to KubeCon you guys want to talk about now? Okay, as I mentioned on the previous call I did put the very rough draft presentations out there so you can see there. I put a link into each section here. There's nothing in there other than the title slide. Feel free to start adding your data or your content in there so people can start reviewing it and commenting as we go forward. Do we want to pick a date for when people should have at least the initial rough draft of their stuff already to put some timelines on us? Yeah, that's what I wanted to ask about. Is there a deadline? I know some conferences want the full presentation uploaded weeks before. Yeah. This one has a deadline. I honestly don't know what it is but I don't think there's any penalty for missing it. Typically in my experience people wait the last minute to get this stuff done and I'm okay with that because people always make changes the last minute but I want our working group to be able to review our content at least in the rough draft form at least a week or two before the conference if possible. So I was thinking of maybe throwing out a date of say the end of April by having the very first rough draft from everybody. Is that doable or are people too busy? Can we pick on somebody? It's a stretch but considering that conference starts in like very close to mid-May I think it works. Is it May? What's the date? It's a little after mid. Well let me ask you Scott, you probably have a fair amount of work signed up here. Is end of April something doable for you just for a rough draft? Scott, you're still there? Sorry, yeah. I was wondering if we have a deadline of end of April for the very first rough draft for the presentations. Is that something that's doable for your schedule? God damn it, Zoom. Yes, it works. Okay, cool. I could just say silent means yes but I didn't want to do that. Okay, cool. Zoom keeps like auto-detecting my mic and muting me? Really? I don't know. That's weird. Okay. What other people think? No one's going to come down hard on us but I just like having dates because sometimes that helps motivate people. You guys okay with starting out with a date of April 30th? Actually, I guess let's push it out until April 30th. What if we just say April 30th for the first rough draft? It could be very, very rough. That's fine but at least sort of an outline of what you want to talk about so that we can tell the group on that Thursday which is May 2nd to at least look at it and see if the high-level topics that people want to talk about are consistent with what they think we should be talking about. Does that sound fair? Yep, sounds good. I prefer May 2nd because first of May is a bank holiday here and we're going to be putting last minute touches. Okay, we'll tell you what. Since it's only two days apart, what I'll do is I'll say May 2nd is a day for the rough draft but with the assumption that on that phone call that we have on May 2nd for the regular cloud event call I will say the rough drafts are there. Please review it to the whole group. My reason I was saying April 30th before was that would give us two days time for sort of an internal review before we open up the full group but we can go straight for the full group too. That's fine. No, that's a very good idea. April 30th is better. It's a very good idea. Okay, here we go. So hold on a minute. Let's see. Okay, I got a run. Okay, thanks Scott. See you next time. Okay, so rough drafts available April 30th with working group review starting May 2nd. Okay, I'll make sure to mention that to everybody to email or something. Okay, any of the topics you guys want to talk about. All right, cool. In that case I think we're done and Doug for you for the demo stuff like I mentioned in the previous call I'm hoping by the end of this weekend we'll have something that's a little more concrete in terms of actually running code for us to start playing with and then on Monday's call we can see where we are and see where I went wrong. Sound fair? Sounds good. Excellent. All right, cool. In that case I believe we are done. Okay, thanks guys. We'll talk next time. Okay, bye. Thank you, bye-bye. Bye. Goodbye.