 Okay, I'll tell you what, let's do one more thing. Dougie there. Okay, we'll catch up with Doug later. Okay, let's go and get started three after the hour. Okay, so I don't need to nag my EIs. I don't think there's anything too exciting on the EIs other than I didn't nag Clemens earlier. He had some things on his list, so we promised we'd work on that. Community time. Is there anything from the community people would like to bring up? Okay, moving forward then SDK. We did just have a call previous to this one about the SDK updates. Small attendance, not a whole lot to mention there other than for those of you who are watching the GoLang SDK, Scott is working with VMware guys to do some sort of harmonization because there were sort of two SDKs floating around there for a period of time and they're working hard to see if they could sort of bring those together and it seems like they're making some good progress there. Scott, is there anything you want to mention about that? I can use some eyes on my code. So if someone is, or if someone has used the current GoLang SDK to develop something and you would like to try out my new version, let me know. All right, cool. I think that's it for the SDK update. Are there any questions or concerns you want to raise? Okay, let's see. Next demo proposal. So we had a meeting last Monday or this Monday. We're gonna have another one next Monday. Scott, would you like to give a quick update on where we are with the demo ideas? So we took some time and thought about exactly what we want to demo instead of the concept of the mechanics of the demo and more of what the demo will show. And so we're kind of working through that piece and if you scroll up, there's a section I think the very top section. Yeah. So we're trying to show the power of standardization. So like what things does Cloud Events let you do today that are today that's hard that Cloud Events may make easier. And so we're gonna show the SDKs and maybe transport bindings. So middleware that allows different transports to connect which is potentially new for this demo that we didn't show last time because it was all HTTP based. And we're gonna try to show observability. So maybe the tracing or tracking ID extension so that we could see events flow through multiple systems through multiple transports and details QED. And then a side goal is we can continue to use this demo idea in the future. So we don't have to rewrite it every time. Yep. All right. Any questions for Scott? Okay. Obviously, love to have more people involved in this. The more people we get involved, the sooner the better this makes everybody can't support it and get some really cool ideas out there. More people that we have the better ideas we usually come up with. All right. Moving forward then, KubeCon planning. So we did have a call last week I believe and we're having another one right after this one to talk about what we're gonna discuss during an intro and deep dive. I believe the current planning is the intro is gonna have our standard, what are we, what are our goals and stuff like that and general information. And that's only gonna take maybe 10, 15 minutes at most kind of a thing. But then use the rest of the time to talk about some things that might be more of a broader interest things like the SDKs perhaps do a demo run the SDKs and stuff like that. And then a deep dive will do exactly that to go deeper into things like lessons learned and stuff like that. We're still kind of working at the details like for example, talking about maybe more advanced hello world kind of thing that are very simple hello world in the intro and then a more advanced one in the deep dive that kind of stuff. Probably the most interesting thing though is originally when I submitted the request for us to have an intro and deep dive I thought that having just those two sessions which are 35 minutes each should be sufficient for everything that we're doing not just cloud events but also the serverless working group itself. Based upon the discussion last week though we kind of realized that maybe what we should do is have a serverless dedicated session just one session and make it an 80 minute one as opposed to two, 35 minutes and kind of turn it into a little bit of a birds of a feather type session as well. So talk a little bit about the state of serverless since you put up the white papers perhaps even update the white papers and landscape doc but then kind of turn it around and get input from the community in terms of where they perhaps would like to see us go in terms of other areas of work they might want to focus on and stuff like that and just basically make it a little bit more interactive. So I did put in a request for the additional session just for the serverless working group and I think we are going to get it so I don't think that's going to be an issue. So we're going to continue our talks as I said after this call and we'll try to fill out the details of what we'll talk about in the serverless session but I did want you guys on the call to be aware that we are planning this third session and not just the intro and deep dive for cloud events. All right, anybody from that list want to mention something that I might have forgotten? Okay, any questions? All right, moving forward then, PRs. So, Rachel, I don't think anything's changed with your PR and I think we're on hold because Clemens was going to put down some ideas that he was talking about in the last week's call. Is that the current status? That's been a shame also. Okay. Yeah, I'm sorry that I didn't do that. No, don't worry about it. Yeah, not a problem. But also other people add in comments too. A few people messaged me privately, that's fine but if you went to like chime in in public and say like, here's what I would like to see out of this that would be great too. Definitely agreed with that, yes. I'd love to get more conversations in the PRs and issues themselves. Yep. All right, so anybody have any questions or comments like to bring up on Rachel's PR before I move on? All right, moving forward then, Kristoff, I'm trying to remember where we're on this one. I think actually Kristoff, are you able to talk even though you're on the train Kristoff? I can try. Okay. It's just a little background noise here maybe so mute me if it's too much. Yeah, it's not that bad. Okay, all right. So I also don't see a screen. So I don't really know where we are. I think in the last call we discussed a lot of things and we addressed all concerns. So I guess this is sort of ready to get approved or not. Yeah, I know. Okay, so just to refresh everybody's memory, I believe on last week's call, the direction we decided to head was to change the must to a should and decrease the size down to 46, I'm sorry, 64K. I don't think, I think the rest of it is fairly much the same as before. It's just basically general guidance on how to measure things and stuff like that. But so that's that first paragraph, that's really the key. So given that, what do people think? Do people still like this general direction? Do I need to start calling on people who wants to speak up? Okay, I'll start going to start calling on people based on who has spoken up in the past. Let's start with Rachel. I think you've had an opinion on this one in the past. You okay with this? Yeah, I think this is fine. I thought that we were supposed to use this past week to see if like, do we have any qualms with this? Like, does this not, is this not okay with anyone's system? I did not personally do that, but I think I have reasons for this is gonna be fine no matter what. So I am personally fine with this. Okay, yeah, I think I did put a comment in there asking people to look it over and if they have comments to raise it either in the PR or on today's call. So Scott, your hands up. So my work with the Go SDK, I've realized that one of the things that this specification is missing is the content encoding strategy, like base 64 or GZipped or whatnot. And that would really dramatically change the over the wire message size. There is a discussion about that. I think Alan raised that as a concern. There's an issue for this. Yeah, I commented on that a couple of days ago. I think it's fine. Yes, yes, yes, yes. And we, was that a me to write that PR? It was kind of implied, but if you don't do it, or if you don't have time to do it. Yeah, if you don't have time to do it, it might be good to say so in the issue itself. So someone else can take it up. Yeah, no, since I apparently have a huge heap of homework, I can just do, because that one is relatively easy. I feel guilty in front of all these fine people. And you should feel guilty. I like that. I know, I'm really sorry. It's just that. Okay. Yeah, actually that one is actually of interest to me because I think that's kind of an important one. Yeah. Yeah. Okay, so cool. Thank you. Yeah, so that will address this issue. Effectively, the content encoding is gonna be echoing what HTTP does. And then that basically describes, this is basically before encoded. And that could also obviously fit that you have G-zip encoding or whatever. So basically, I think that section is gonna steal straight from HTTP. Okay. But let's circle back again to Scott, your comment. Do you think that this, that doing a different encoding scheme, as you said, it might impact the size of things is, are you suggesting that 64K may not be the right size or you just bring it up as a thing to think about? No, I'm not concerned about the size. I think it's just the, for example, if you base 64 encode something, it becomes bigger because it's more bytes. So the representation that the message is before encoding for JSON format is not a potentially an accurate way to measure the over the wire size of this message. Oh, I see what you're saying. Is that, is that something that you'd like to see addressed in this PR or follow-up PR or is it something you're not sure we need to? I don't know if it's a real issue. It's just like looking at the text could be inaccurate, like in a technical point of view. Can I ask a question? So I wrote this big third or last paragraph where I'm trying to describe that it's the over the wire size doesn't matter. What matters is like, sort of we try to measure it independently, just only the cloud event and product we use the JSON format, but it's just for measuring it. The over the wire from size doesn't really matter because it will be different depending on which format we use. Does that program not make sense or am I missing something? Well, I think there's two forms of the JSON format that the message could be sitting in. There's the encoded version and then there's the decoded version and those sizes could be very different. Okay, so I, we should, well, basically the text then should say which one it is and then the problem is solved. Right? Okay. Is that something you guys would like to see as part of this PR or follow-up PR? How do you guys like to work that? In general, it should be, we should be talking only about the wire size because that's what matters. And maybe the discussion of minified is maybe a little much here, like for my personal phase because it's that big and if you have in your encoding mechanisms to go and make it less big, well then go and use that. But I'm not sure, I'm not sure we, it's, it seems a little strange and a little wordy here for what we're trying to express. Like I'm going to say the wire, the wire size of the encoded message, should be, should accept that up to the size of 54KB and there's a lot of extra wording here that might not be necessary. So, okay, I'm trying to figure out how to make progress here because this issue's been out there for a while and I don't know whether Kristoff is feeling frustrated or not. It just, from my point of view, this thing's been out there for a while and we need to sort of figure out some way to wrap this up without letting it linger on too long. And Clemens, you're now suggesting that perhaps we shouldn't be talking about this mimification kind of thing. It's rather just, what are the bytes of the wire period, right? Since this is normative text, I think the normative thing is effectively, the first sentence up to the comma and the rest is mostly example implementation ends. Well, sort of other than it does use normative, RFC keywords and stuff. And it does talk about using the JSON format to figure out the size. So it's not just. But it's like, if you use CBOAR. Well, so let me do this because Kristoff has put a lot of work into this and he typically only seems to get feedback on the call itself for the most part, which is, from my perspective, if I was in his shoes, I'd be kind of frustrated having to wait a week before every subtle comment comes in. So, yeah, so I'm trying to figure out I feel like I have to say this, but I don't want to, because Clemens, you already have a lot on your plate, but if you're suggesting an alternative here, could you write that up so people can look at it and compare it? Because I don't want to sit there and say, hey, Kristoff, can you go do Clemens' idea? It's not fair to him. Yeah, okay, I'll do that. Basically, there's a, I understand what the thought process here is of the method by sterilizing part of it, that's Jason. Right. But, yeah, I'm not happy with that. Okay, well, I don't want to rush that. It's not clear to me that on a particular route, we go and reserialize and reserialize the event so much and that kind of normalizing on Jason will house us so much. Let me, I'll put that on my homework list. I'll write something up. It's not going to be essentially different. I think there's just a little bit much of focus on particular aspects of Jason. Like it should be self-explanatory that you throw out, that you don't do a pretty print formatting for Jason. Okay. Okay, so Kristoff, it sounds like there's at least a little bit of concern between Scott and Clemens that maybe the wording isn't quite right here. I assume you're okay with this being delayed a little bit. I don't think it's critical that this gets in, but we're also not asking you to do any work to modify this. I want someone else to put forward a slightly modified proposal that we can consider. Is that fair with you? Yeah, I tried to, I didn't catch everything I wanted to send, but I tried to listen to what Clemens said. And maybe if I get it, I can also make a proposal that Clemens doesn't have time. But I mean, I'm happy to make changes where time frames are a little bit accelerated than what it is now that we're great. Yeah, but other than that, like if you drop me, yeah. Yeah, what I'll do is I'm not gonna go into a different PR, I'm gonna go and effectively write down a suggestion into the PR in the comments and then you'll see whether that's okay or not. So basically, I'm gonna write an alternative version of this section, but I'm gonna use it, I'm gonna put that into the comments of this PR. Yeah, please do not open up a set of PR, we don't want to do any PRs. I'd rather have the, like a modified proposal text kind of a thing as part of this one, that way. So that's what we'll do. Yeah, okay. Okay, excellent. Thank you guys very much. Okay, cool. And Christophe, thank you very much for your patience and work on this one, I really appreciate it. No worries. Okay, any other questions or comments on this one? All right, cool, thank you guys. Looking forward. The data ref one, I know Christophe, you made a minor update here, but that wasn't actually what we were really blocked on. So let me just quickly show that minor update. Hold on a second. Yeah, I added, Casey had some questions. I think there was some, rather than I made this, I did this one sentence that should be, should clarify that data and data ref, information behind it must always be exactly the same, must be then equal. Yep. So that was sort of confusing before maybe and now it should be really clear. Right, I see that, and I'm highlighting on the screen for people, but I believe the action item from this one that was supposed to be done was Clemens, you had some concern about potentially doing this same type of thing, but without adding another attribute called data ref, possibly reusing data itself. Yeah. Yeah, that would have been effectively, that's an implementation. Instead of doing that, put an implementation note in. I'm okay with the text as it's written. I'm just not sure we need to have that attribute, but that's something that the majority should really just go and decide. I think it's a little, I think that extra attribute is something that we can also do as that can be an element in the payload. But I also see that the advantage of having something that's generic, so that generic implementation could potentially go and then pull the data from the reference place and then kind of present the event as if it was flowing all the way through as one. So I could see both sides. Right, but I think you had the action item to go off and try to write down what you were actually thinking as a slightly alternative proposal here, right? Yeah. That's what I was getting to. Oh, yeah, this is a terrible call for me. Okay. I know we're picking on you big time. So it's a pain in your hands up. Yeah, I just, not totally the same, but similar to Clemens's thing. The only thing I'm worried here is if all, if this is part of the main spec, are all implementations like thoughts have this? I believe the intention was that it is part of the main spec, but it would be optional. I'm trying to figure out whether the optionality means optional to use or optional to support as a receiver. No, it's meant to be optional as a, I mean, as a receiver, if you get this data ref, so basically my attention is someone does not want to send the full data up here. And then I will add the data ref. And then as a receiver, if you have someone who would send that or a middleware, you know, would change your rent, then yes, you have supported. But if you're a middleware, you can just forward it and you don't really have to do anything about it if you don't want to. Yeah, but say I have an API that accepts cloud events and I need data because what I need is in the data. Am I compliant if I reject events with data ref instead of data because my implementation doesn't support it? Well, I would say yes, because the data ref doesn't really is not, it's not always meant that you are able to get the data from there. So for example, if you have these more security focused patterns, where only a specific receiver who has a pre-short secret should access the data, then you as a generic consumer cannot read the data ref. So that's the case where I think you're still in sort of compliance if you just consume the event but don't do anything with it. Obviously not very helpful for you use case. There actually might be a broader question here about as a receiver must it support all the, but must it support the semantics of every single property or can it reject a message because it doesn't support it and still be compliant. But, Tam, I think you had your hand up for a sec. Did you want to ask something? Oh, no, I was going to mention the same sort of things when the data payload may not be visible and it might be convenient for the data ref to be there. So it was covered. Okay. Okay. So Tapini, did you get your question answered? Well, yes, with another question, not an answer. That's kind of helpful. Well, personally, I would almost rather wait until we sort of nail down what the final proposal looks like before we try to answer that question. Because for example, let's say we come back with a proposal that says, okay, we don't need data ref. We can do this claim check thing using just the data attribute. I don't think there's any doubt that everybody must support the data attributes in general. The question is then, do they need to support this claim check pattern that's encoded within the data attribute and we can decide the optionality of that when that comes up? Well, actually that answered my question in the sense that it's not answered because, well, I guess what I'm asking is, or requesting is that it's made more clear whether it is inside the data or the data ref attribute, whether it's optional to support this at all. Are you still in compliance? Because it's not clear in the text right now. So Chris, I've correct me if I'm probably going to train, but I think you said it would be a compliance notation if the receiver rejects the message, if it doesn't support a claim check. Well, I wanna say this. I don't know what exactly you mean with reject. So you would say, I cannot process this event but what is supposed to happen at this point? I mean, you get events and either you understand them or you don't and in this case, for some reason you don't, but this can happen for any sort of reason like the sender introduces a new type of rent and you don't understand this event. There will be another case where you can't process the events, right? Or maybe I'm on a wrong track, I don't know. Well, sort of. So it's interesting to me. For me, it's sort of, yep. Sorry. No, go ahead, go ahead. So for me is you get an event and either you can consume it or you can't. So one of the reasons you can't consume this because you don't understand how to get that thing out of the data ref, what there may be other reasons why you can't consume it. What I don't understand is what you exactly mean reject because who understands, what is rejecting? What do you expect from you rejecting the events going to happen? That's a valid question. I guess I'll be in trouble more like, but yeah, sure. I get your viewpoint. I don't have an answer for you yet. What's the, what are the rules for visibility of that location? What's your thinking here? Because it could be, since we're, since we're ultimately cloud events is a messaging path and that may go through routers and might go across a networking, across network boundaries, which means you might quite well have a scenario where you come out of a private network environments on the edge and then you transition into a cloud environment and then you transition back into a VNet. And now you have a cloud event and you have a data ref and that data ref is now pointing to something that sits over in that private network at the edge. How does that work? So, my view on that is it kinda is similar to what we have with this schema URL or even the source, which are also your eye references. There is no guarantee necessarily because they can be relative or they can be also absolute but there is no guarantee that you can actually access this your eye. Yeah, but those are different. Schema URL, and schema URL is typically a pointer to your cache even though it might be a real location. Source is very clearly only an abstract identifier. And so both of those are just your eyes. But here, I think you literally need to have a URL because you need to go and get at that data that's being pointed to. Well then. So you would have to define a, you have to go and write down a rule here that speaks about the relationship of, publisher and consumers and that they have to have visibility to this because the data is an integral part of that message. And what you're doing is you're basically, you're pushing that off to a different place but it needs to be assured that anybody who received that event is able to consume the entirety of that event in some way. Okay, so that is an assumption that we can make and then I can change the text in the message. I didn't make, in the specs, I didn't make this assumption. What one assumption I made is that similar to encryption you may encrypt the message and make sure that only a pre-selected set of consumers can decrypt the message, right? That is one use case we may want to support and sort of this one here will be similar to encryption you don't encrypt it or you put the data into the data rev and you don't tell anyone how to basically get there because they need a secret, for example. So you get this message or this event either you have the secret you can access it or you don't have it, you can't. And that would be one use case. Yeah, and that's exactly why I'm like if this isn't the data and the data payload then you already, then you have a constrained audience which understands what that data payload is it can then go and agree on what the specific semantics are of attributes that are in the data of that particular event, which may include being able to go and get at particular data items that are too big to include or objects, pictures that are being referenced, whatever with ultimate representations of some sort. And that's something like if you have the we started with our first demos where like the block created events for storage and they all point to images that are too large if you would not include in that event. But that's a claim check pattern implementation arguably that then is fairly specific for the particular cloud storage system because they're all somewhat different. And so in the interrupt demo that we did we had three different cloud storage services or four. And so the implementations have basically got the respective events, they could generically figure out where does that come from? What's the source of this and what's the event type? And based on that, they could go and dispatch into a handler that could then go and extract the image according to what kind of event that was. But there was always some idiosyncrasies to the particular storage services. And that's all encoded in effectively that in that event payload and that has worked. I find your proposing is super generic mechanism, right? But at the same time, there seem to be a ton of exceptions for it that then require kind of a negotiation amongst a set of consumers and producers. And so I'm wondering how generic that mechanism really can be. Okay, so I mean, right, I tried to make it very generic. There was my first approach, but it's completely relevant to make a really concrete approach and say, okay, it has to be an HP URL, it has to be public, has to be accessible from anywhere. That gives out a few use cases, but it makes sort of everything else easier, I'd say. What it also means basically that the data is then always on the public internet. That's the downside and I'm not sure if everyone would be happy with that, I don't know. That's what I see as the trade-off in that approach. And also that you can't dango and use the Azure Bob storage. It probably also has some HP URL, but you can't use the native access method for it. But I guess I'm a little confused. Clemens, were you actually suggesting that we get as prescriptive as what Kristoff was saying there, things like the URL has to be publicly available? I can't imagine that, but that's gonna work for everybody. No, but there has to be a rule that says, or there has to be at least mention of, that the consumers and publishers must share the same, basically both need to be able to see the data ref, where the data ref points to, within a given system obviously does public. Right, but the text that I highlighted on the screen, that Kristoff put into the thing where it says, the location may not be accessible without further information, such as a shared secret or something like that. I interpreted that as there may be environmental concerns or details that you need to work out before you can actually talk to that URL, but that's something that we can't necessarily specify in the spec, do you think? Yeah, but that's, I think that, I find that a little weak for that particular concern. And that is, so here, when I read this, I would think about, oh yeah, of course you need to have some credentials. But it's really like, because of the complication comes in because we might be propagating cloud events across system boundaries. And it's so clear that once this consumer gets that event that it then in turn has access to the particular location at all. Right, that's a little different than, it may not be accessible without further information because if that object is sitting somewhere in the system on the edge, you might not be able to get it all at all. Like there's no path. So okay, I'm trying to figure out whether you think that there's a fundamental flaw here or it's just a matter of the wording isn't quite what you'd like to see. It's, for a generic, so I think for a generic mechanism needs to be made clear that the publisher and the consumer might sit in, might be in different networking scopes and that you have to pay attention to that. So I wanna have it more explicit. Okay, so do you like to see some more general guidance at some point? That's right. And then the last clause here, if this attributes is used, the information should be accessible long enough, that is arguably, how long I wanna go and store that is not the specs business. Right, okay, so it sounds like basically what you're saying is there may be some additional information that may be appropriate for say a primer for additional guidance around this stuff because the spec can't be too prescriptive. But there may be primer material here somewhere, but it's basically what you're saying. And that's fine. I don't think I'd be able to disagree with that. But it also sounds like you're not necessarily against, in principle, this idea of a code check, it's just the exact syntactical format of it is something you think may be better done through use of the data attribute, right? Yeah, I still believe that data attributes to better place for it and better place for it because you might have more information and then you can put into this one field here or into this one URL and you might have, you might have one event may actually carry multiple references to external data and not just one. And then you're ending up in that situation where you have some of those are sitting in data with external references and then you kind of end up with the corner cases being able to use this data ref thing. Right, okay, so I think though in terms of the next steps here, you haven't actually time to write up your slightly modified idea here for how to solve this particular problem and you're gonna write that up as a comment in this issue or in this PR. The other aspect though is, I guess it's the one that Tapini was bringing up which is what does optional mean in this particular case and is that something we need to think about once we agree on the exact mechanism that we're gonna potentially add to the spec? Because I'm not 100% sure that everybody's on the same page about what optional means for this particular feature and possibly even for the entire spec in general as a receiver. So what I'd like to do is I'll take the next time to open up an issue just so we don't lose track of this to make sure we revisit it because I do think it's an important one because I do think I understand the optionality of all our properties is very important to make sure you understand who's responsible for supporting it and when they can not support things. And I just want to make sure that's very clear. So I'll take the next line to open up an issue to discuss that but so Clemens, if you can write up your modified proposal as a comment in this PR relatively soon so people can think about it before next week's call, I'd appreciate that. Yeah, I will do as much homework as I can tomorrow. Okay, thank you. Okay, are there other aspects related to this PR that people would like to bring up? Okay, I think we know, I think this data reference, I think it's a good feature, but as an event consumer if there's such a reference, so the event consumer does not need to go deep into the data payload, can just get the information from this reference. But with regard to Clemens other comments about this, the type, I think probably we can work a little bit more on that because I'm not sure whether the URI can represent all the locations that the payload is saved. I'm not sure about that. Interesting. To tell you what, Kathy, because I think what you're concerned about there is almost a tangential issue to the mechanism of how to represent this in the message or in the event itself. Could you think about what you'd want to use instead of a URI? And when you think of what you want that to be, can you add that as a comment into the PR itself? Yeah, okay, I can add that. But I myself, I don't know how to, what other types. I'm also whether, like Clement mentioned before, if the information is stored in several places, different types, how we are going to represent this? Is this a single URI enough or we need to have a big stuff that? I would assume Clemens proposal would address at least the part of that already. Okay, that's good, okay. If there's at least of the URI or something like that, okay. Yeah, but it sounds like your concern is whether URI is the appropriate type. And I think that's the first time that that question has been brought up. So if you think there is another type other than URI that might be appropriate to represent the location of the data, I think it'd be useful if you could put a suggestion for what you'd like to use other than URI. Okay, I'll think about this. Okay, I appreciate that. Because if there was something better, I'm not sure if we were against it. We just, URI seems to be the things most people's minds default to, so, okay. Anything else related to this one people want to discuss? All right, cool. In that case, again, Kristoff, thank you very much for your patience and work on this one. I know this one's not easy, but we appreciate the effort you put into moving it forward. Tepini, deprecation. I don't think we've actually talked about this one yet. I can't remember for sure. I think I might have mentioned it on last week's call since you were, I don't think on the call. Do you want to talk to this one and give a summary of what you're thinking here? Sure, so there was an issue opened by someone who had no recollection. Who, about how to single deprecation of events or delivery methods or anything, I guess. And there was a discussion where some ideas were thrown around. And I think Doug and I and someone else also basically said that, yeah, it would be cool to see or signal deprecation on the wire, but we don't want to prescribe too much specifics beforehand because it can be the need and the use case for deprecation can be quite varied from use case to use case. So I wrote up this as a draft of what I think should be the direction as I think it would be valuable to have an extension to standardize the single deprecation. So consumers can, for example, alert an operator to react, even if they don't know how to handle the specifics of the single or the contents of this attribute. Some comments I haven't addressed and I apologize, I've been quite busy for a few weeks. Okay, and just to be clear for everybody, this is a proposed extension, not a formal property inside the specification. So the bar for adding it is definitely lower than a full-fledged or a first-class property. All right, any questions for Tepini? Has anybody had a chance to really look at this? Okay, nobody raised their hand. I'll ask a question. It's not clear to me what the values would be for these two properties. Yeah, I... Description here almost sounds like a Boolean. I mean, yes, but as I was trying to describe, that is kind of the idea. That's where I've been laughing at trying to come up with an example because I don't really want to make an example. I'm just... Because I think it's valuable, as an extent. This is why I don't want it in the main spec, by the way. I think it's valuable to have somewhere to look at for deprecation, that you're not going to get these events anymore. Let's say you're listening to a GitHub pull request version one events. They eventually 10 years from now decide to discontinue the delivery of those events because it's a legacy system. To me, it's quite valuable to know that if I look at deprecated field, I can know something's up within the bend. I'm not going to get that anymore at some point. But how to signal that? I don't quite believe I know how to answer that question. And I kind of agree very, very, very much with your viewpoint in the issue that we even shouldn't be describing that. And that's why it's intentional, left so open-ended. Well, I was kind of wondering, whether it needs to be actually split across two properties. Whether you could just have a deprecated string and the fact that the property is there at all means it's deprecated. And the string just tells you some human readable description of why it's going away, where to look for replacement, that kind of stuff. And that's sort of producer-defined. But you could actually all that within just a single property. That's completely fine with me. As I said, I'm not heavily invested in anything that's in the proposal. The deprecated type was, I included it because it was an idea that might help someone. Because if we prescribe nothing, it's basically a Boolean. I wanted to encourage someone developing a more sophisticated use, I think, than Boolean for the field. But I'm completely fine with removing it and just letting it play out. I'm sure someone will come up with something more useful anyway. I was thinking more in the line of a URL, doubling to an explanation of the deprecation in the deprecated field, for example, as the most simple use case. Were you thinking of at some point, perhaps, information in these two fields could be used to programmatically figure out how to fix things? Like, something in there would tell you, okay, this field's going away, but maybe in the future, it's called this instead, and people should be able to programmatically analyze that and make some changes on the receiving side as a result, or is that too sort of AI-ish? Well, yes, along those lines, for example, if you're going to deprecate an extension, that's, how would you do that in the future? I guess the deprecated type, actually, now that we discuss it, doesn't add that much value. I think the main point I'm looking for is the fact that it's just signaled, and you can find more information somewhere. Having the information encoded actually doesn't make that much sense anymore to me. If someone comes up with a good way to do that, I guess they'll use the field for that anyway, since it's left open-ended. So, yeah, that actually sounds fine with me. I'll remove it unless someone has an objection. Okay. Anybody else have any comments on this one? Let me ask this question. What do people think about this as an extension at all? Is there any objection to even continuing down this path? Or does someone think, nope, this is a complete mistake, even as an extension, they don't want it at all? Okay, I just want to make sure that there's, oh, go ahead, sorry. We can always deprecate the deprecation extension. You've been dying to say that, haven't you? Okay, well, like we all know, right? Extensions are meant to be sort of experimental in some way, so if this goes nowhere, then you eventually made it die. That's fine. It's not like it's a version change for us if we drop it later, just an extension. I find that question very interesting though, can you? What, deprecate the deprecated flag? Yeah. I suppose you could. But it's not, actually, you don't, but you don't use this to deprecate flags or properties. You use this to deprecate events, right? No, no, read through it. You can deprecate any freaking thing you want. Oh, I missed that. I apologize. That is part of the intentionally open end. You can use it to indicate anything you want. Oh, you're messing with my head now. So Clemens might, let me say to you, yes, of course you can deprecate it. If you don't want to have a deprecated attribute, i.e., you don't want to signal the removal of features in any way, then why not deprecate an extension? Okay. If you're not going to be considering deprecation or removal of features in any way at all, you don't want to be involved with it. I don't think it's in any way expected of you to not be deprecating extensions. I like that. But isn't the sentence that I highlighted where it says the deprecated attribute indicates deprecation of the event delivery? Doesn't that kind of imply the entire thing? Okay, so that's a mistake of my part. I was very challenged by trying to come up with a sentence to describe deprecating anything. So that was the best I came up with. But now that you say that, I guess that isn't very clear. I have to think about that one. That's a mind boggling concept. Because that could be actually quite complicated after a while. That's what I'm saying. We need to leave it open and that we... Interesting. Okay. Thank you, Scott, for completely blowing my mind. Anything else you guys want to talk about? This one sounds like more thinking maybe need to be done here. Yeah, I'm also going to work on that. Yeah. The language and remove the deprecated type and throw in an example of a URL linking to a blog that explains why this event was deprecated. Yeah. Interesting. Okay. Thank you. Last chance. Any questions or comments on this one? All right. Technically, we're at the end of the main agenda and I don't think we have a whole lot of time to go into anything too deep. Clemens already got nagging reminder about that one. Oh, this one, it's fine to mention. There's an issue out there about the scope of the idea of events. I think we say it has to be unique but we don't formally say the scope of it like... Or actually, maybe I'm sorry. I think we say within the scope of the producer. But then there was a question about should we basically be more formal and say source plus identifier, the combination of those two fields needs to be, for example, global unique or something like that. I wanted to... I don't mind writing a proposal for that and taking the lead on trying to push something through if we want to. But I wanted to get a sense from the group. Do you guys in general agree that source plus ID needs to be global unique or is there some other sort of mechanism you guys were thinking of to determine uniqueness for these things? I think that's right. That's impossible to guarantee. Yeah, I was gonna say I didn't really like that idea. So again, well, we're running out of time. So I'm gonna quickly, Scott, can you explain a little on why you think that's impossible to guarantee? We can because, well, there's no... There's guidance on what source can be but there's nothing that says that it's like a resource pointer. And there's guidance on ID but it could be a sequence number if you really wanted to and still be compliant with the spec. So I could have internally unique events being produced but they'd conflict with another cluster or another producer. Yeah, I think I'm going to say the same thing unless we can have some place, some repository, some place for people to register this. Otherwise, if the different sources they do not cooperate with each other. Interesting. Also the idea. How we can ensure they're globally unique. I see this as like the same issue as IP address is not globally unique because there's subnets and stuff. Right. Okay, so let me ask this question. Do you think it's pointless to even get more clarity on this point? Or is it just a matter of finding the right wording to correctly define what uniqueness means? I think it's how we can enforce this. If we say it's globally unique, right? I think that's- Well, no, I'm not suggesting we use the word global unique anymore. What I'm saying is, is there the right term? Is there a good wording that we can come up with to add some clarification here? Or if, or I'm wondering is whether trying to add more clarification is actually going to make things worse. And we should just close this issue and not touch it at all. Is the problem that there's confusion on if a single producer can produce events that conflict with itself? I think the question was raised because the spec says the ID must be unique within the scope of the producer. And there was some questions about, okay, what does that actually mean to be unique? And is it unique within? Does that mean it's unique within the scope of some nebulous thing called producer? Or does it mean it's unique within the scope of this source URI kind of thing, right? How do people determine uniqueness? I think that's where this thing came from. And I'm okay with us coming back and saying, hey, we're going to leave it a little bit vague and leave it as is. But if you guys think, no, we need some kind of clarity, we just haven't find the right wording yet, then I'll keep noodling on it and try to come up with a better language and we can keep going back and forth on it. I just want to know whether I should bother to waste my time on it. I think we should clarify the scope, the unique scope because that's, I think that's important. Okay. I think this is clear for me. Opposite into the spectrum. Okay. Okay, tell you what, so if we're running out of time, oh, go ahead, sorry. So one thing, maybe we could put the type, the event type into it, because the event type should be prefixed with a reverse DNS name. So at least that part should be really globally unique because only one person can register a DNS name, right? So if we put that into it, and then people have to make sure their sources are unique in a way. So if I'm, I don't know, I have an open source product and everybody can deploy it, but then I should, as the open source product provider, I should make sure that each source somehow uses something that makes them unique. Does it make sense what I'm saying? I understand what you're saying. Yeah. So let's say, let's say I patch the Kafka and I, for some reason, I produce events and that is deployed until many places, but then each user of my open source product must then make sure their source is unique because source can be a URI reference. So I don't know, maybe Kafka would have message slash ID, but that wouldn't make it unique if I had two different deployments of it, right? If my ID start counting at one. So then that is not a good source. So then what Kafka should do is they should force, or maybe Kafka is a bit of a fool, they should force people to use a full URL again. So another relative URL, and then it should again be globally unique because then the type is unique, but it's sources and then the ID would also be unique. Right. Does it make sense? So I'm gonna have to call time here just because I wanna be respectful of people's running off throughout the meetings and stuff. I think I got enough information for me to just try to come up with another proposal and see what people think, but I do think it's gonna require a little bit of wordsmithing. But with that, let me just do the roll call last round before we adjourn. And keep in mind, we do have a phone call after this for the KubeCon sessions. Fabio, are you on the call? What about William? Yep, I'm here. Okay, thank you. David Baldwin? Yes, sir. And Klaus? Yes. Jude? Yeah. Okay, Vladimir ping me offline so he's definitely here. A Doug, are you there? Doug, do we lose you? Hey, okay, here's the mic issues. Fabio, are you there? Okay, did I miss anybody? Okay, thank you guys very much. And we'll continue the discussion next week. For those of you for the KubeCon sessions, please stay on the line. I'll drop off and I hope they'll come back before I leave. Okay, sounds good. Thank you, Clemens. Okay, thank you guys. We'll talk again next week. Thank you and bye. All right, let's see where are we. You guys, give me just a sec guys to get myself organized here. Scott, I assume you're there. Chad, Jude. Actually, it looks like Doug is half, it's weird. There's no mic, or actually, sorry. I need to scroll, okay. So Doug might still be there. No, BRB. What? Say that again? I will BRB. I have no idea what that means. Who's at 612-618-5997? I don't think that's John Mitchell. I don't know, that is me, but I'm still here. Yeah, I know, I got you Christoph. Jude, do you have your hand up? Does CNCon mean CloudNativeCon? Yeah, we're talking about, this is planning for KubeCon, CloudNativeCon in, where is it, Barcelona? Okay, cool. Yeah, I will just look for the full form of CNCon. Yeah, I don't have to do it real handy. All right, let's go ahead and get started. You may spell my name, but it's okay. Oh, sorry. No worries. Thank you. All right. Oh crap. That's the wrong button. All right. Let's see, where were we? So Dan Barker pinged me offline. He's probably not going to make the call today, but he said he was definitely interested in possibly talking about the who are we, why are we here, that kind of stuff. Is there any objection? Does anybody else have a really strong desire to cover that part? Otherwise I was going to give it to Dan. I'm sorry, not Chad. God, God. Dan, not Chad. Okay. I hear anything. Okay, so, didn't have anything formal planned here that we just need to get more clear on what we're going to be talking about here. Has anybody had any more thoughts in terms of how to solidify all these different topics we brought up last time? So for example, Scott, you were talking about doing a Hello World sample in the intro. Have you any more thoughts of that in terms of how you can, how you see that looking or what you want to talk about? I'll tip to that. Yeah, I've been kind of, I've been building up clients around the Go SDK in kind of this idea of make it as little as code as possible to start sending events. Okay. Now you've, in terms of what you want to actually showcase there, obviously you can use something like Go SDK as a sample of saying, hey, look at all the great work we're doing around SDKs and look is your life really, really easy to use this stuff. But were you thinking about some sort of Hello World, like live demo to showcase these things and therefore we need to get the other SDK folks involved to make sure that their stuff can participate in that? Yeah, I think that's an open question. I know a lot of languages, but not everyone. So. But it, but you do want to, it sounds like you do want to do perhaps some sort of demo there are leveraging the SDKs, right? Yeah, I was thinking like a live typey thing if we have time for it. Okay. Do you see this leveraging the same demo code that we're talking about in the other phone call or do you think this is. No, I think in the intro it's just like, if you would like to add sending cloud events into your existing code, this is the, here's a little code snippet to show you how to get started. Okay. And then like maybe this is what it looks like on the receiving side to receive a cloud event. Okay. It's like, it's like active integration. All right. I have returned. Howdy. Hello. My boss had had has a crisis, which is great for us. Yeah. Okay. There was a term used there. I like what was that? Active integration. Was that the phrase you used? I don't, I don't remember the recording. It was a catch a little phrase. I liked it. I think it was like active integration. I interpreted that as potentially. A live coding session almost to add it to it to an existing piece of code. To show it. I mean, yeah, that's, that's an option. Yeah. We can show the, some like something and then a slap in some cloud event sending instead. Kind of Kelsey high tower ish. Yeah. Like, look, your life's super hard, but check this out. Yep. Okay. That sounds good. So. We didn't, we also talked about tips and best practices. Now we have 35 minutes. If you assume. Dan and this stuff is going to take. Some are between 10 to 15 because this is also going to include, you know, what's new since the last time we talked to these people. So that could be, you know, somewhere between 10, 15 minutes. Scott, that would leave. 20 minutes or so left for this stuff. How long do you think you need? Because what I'm wondering is whether we have time for. Best practices. Or our tease of the bigger demo or whether we say, no, that's going to be press for time. We need to push it out to the deep dive. We might not have any tips yet. That is true too. So, okay, let me poke on this because I can't remember who, who asked or who meant to the idea of the tips. It was me. Okay. It was you. Good. Were you thinking of tips of. Gotcha is relative to crowd events in general, or tips relative to using SDKs or something different. I guess, you know, there's like the general tip of potentially you, your data is not the actual content of the data, but like, like if an image is uploaded to a bucket, the event doesn't have the image embedded. It's the, a ref back to the bucket that had the image dropped in it. For example, like those kinds of tips, just like noob eventing tips. Got it. Okay. Okay. So it sounds like maybe we need to wait a little bit to sort of brainstorm a little what those ideas might be. And if it's a long list, then maybe we don't have time in the intro way of the short list. Maybe we do have time to mention it in the intro, right? So we can wait on that. I guess. Yeah. Okay. I mean, it could be like a one minute. Oh, by the way, if you, if you're looking for like, big best practices for eventing, here's our thoughts. It's like a slide of like several. Well, I was going to say, technically we have the primer, which we already do have some, it's a mixture of things. The prayer, right? Some of it is explained the rationale for some of our design decisions, but I think there are some guidance things in there. I think I need to go back and double check what the night be, but I have this vague recollection. We have at least one or two things in there for guidance. Great. Yeah. So that might be something to pull from. So. Yep. Okay. And we definitely need to add more. I think, for example, I think somewhere on Clemens long to do list, he has a, at least one thing to add to the primary relative to this stuff too. So whatever, whatever that thing was, we can add that to the list. I just came up with what he did offhand. Yeah. All right. And I guess the same thing applies then to the potential demo, right? Depends on whether we have time or not to sort of give a tease for the deeper dive session demo. Yeah. Okay. So let's focus on the deep dive then. I'm trying to remember, were we thinking of two separate demos here? Or do we think the hello world would be now? Cause the hello world is definitely not the, the factory thing you talked about. So are we thinking actually doing two different demos here? Yes. I think that's the, that was the plan was dropped down in the code a couple of times. Well, I don't think you're going to really show code for the demo. You might show some like, you know, you know, you know, we're leveraging what we just did with the, the simple version. We rewrote a complex version. And, and here's the rigmarole of how it operates and flow through. Okay. So taking the hello world from the previous, from the intro and adding something like trace ID to it. Oh, oh, for, for the live coding sessions. I don't know. It could, I don't think it has to be the same. Unfortunately, Vlad is another call to talk about this one. Yeah. So, okay. What about this section here? Is there somebody on the call who would like to take lead? Any other, at least. Flushing this out and, or potentially presenting. Lessons learned. That's kind of my topic, isn't it? I was wondering if you're going to volunteer. Yes. Ah, I can, I can, I can do that. Having, having a contents in the, having content in this. Okay. Is there anybody else who would like to possibly toss an image of the hat on this one? Okay. Not hearing any. I'm assuming then that between Vlad doing something interesting here, Clemens with his talk on this stuff. We probably won't have a whole lot of time for anything else beyond potentially a showcase of the demo, which is the factory stuff that, that's got taken lead on trying to form our order to, to flesh out. So I think between these three topics, we should definitely be able to fill up the 35 minutes. So technically this one would be all, right? And are we assuming Vlad is taking lead on this one? Is there, is there somebody else in the call who would like to take lead on it? Or should I dump it all on Vlad? Can you do me a favor and because I don't see a screen. Roughly say what you're talking about. Oh, I'm sorry. I forgot that you're on this train. Yes. I'm talking about, in the deep dive session, we have a bullet on there that says, another hello world example, but with extensions and for example, trace ID. And Vlad had a suggestion of, of his deployment pipeline application that he has, that has been working on. So the point of this one was to showcase extensions as well. Okay. Okay. So is there anybody else who'd like to sort of put their name in the hat, name the ring on that one? Or is it okay for me to try to see if Vlad wants to take lead on that? I think he did want to take a lead on that. Okay. Not hearing anything. So what I think we have now is in the intro, Dan would do the, who are we kind of thing? Scott would then talk about the SDKs, live sample, hello world type thing. Whether we do best practices or not, it would be a based upon whether they've been covered with a good list. And if we have time, we'll have to see whether we can do something with the, the demo thing there. Oh, Jude, your hands up. Yeah. Sorry. The deep dive is about 25 minutes long. I'm sorry. Yeah. Correct. They're both 35 minutes. Yes. Right. So wouldn't the demo itself take more 20 minutes to kind of explain like given all that we're doing in the demo, wouldn't it be like a large piece of the deep dive? I don't know. I could say going either way, because obviously you could probably spend a lot of time doing it, but if you don't necessarily go into the two level, two, two, deep detail, you could probably summarize what the demo is doing in like two or three minutes. And then spend the rest of the time just showing it in action. I don't know. Scott would, since you're, since you're taking a lead on this one, Scott, what, what do you think? Yeah, I would, I would think that the, the longer explanation for what's happening in the demo would be in a repo somewhere so that people could go and peruse it at their leisure. Okay. Yeah. Cause I don't think that, I don't think showing the demo, it should necessarily be too technical in terms of getting under the covers. It's more showing how cloud events can be used in more of a real world scenario. And maybe as part of writing the demo, we can show the cloud events flowing between the systems, you know, by clicking on a button or something, you can actually see the cloud event that got sent between the, the factory and the, and the delivery system kind of stuff. But I don't think we have to go too deep under the covers of how that actually worked within the component itself. Yeah. Exactly. Hopefully this would be something useful for somebody else that's stumbling upon and trying to learn about cloud events. Could check out and see. Maybe not it running live, but understanding how pieces can assemble together. Yeah. Okay. Okay. Cool. Thank you for the question though. Okay. So we got that. We'll figure out if, if we do decide to do the best practice and tips and a, and a tease of the bigger demo, then we'll figure out who won. To do that, or we'll just dump it on Scott and seize up on stage at that point. Anyway, we'll figure that out later. And then deep dive. We got Vlad for the hello world with extensions, Clemens, the deep dive. And then everybody involved in the bigger demo for the factory thing. Is that sound right to everybody so far? Any changes people want to make? Good. Okay. And then for the serverless session, assuming we do get the 80 minute one, which we should be doing. Actually somebody. No, wait, I'm sorry. Dan ping me. He said. Oh, okay. Yeah. So Dan mentioned to me that he didn't, they was also not just interested in the, who are we kind of thing, but he was also volunteering to. Potentially help us with the updates of our documentation from the serverless working process. So we're going to do that. We're going to do that. We're going to do that. We're going to do that. We're going to do that. We're going to do that. We're going to do that. We're going to do that. So Dan was volunteering to help out with the documentation from the serverless working group, meaning the white paper and a landscape doc if we need to. So Dan was volunteering to help there. Okay. I just wanted to get that in there. But so anyway, we're talking about the state of serverless, which obviously related to what's changed in the community recently and then turn it into a birds of a feather session with the community telling us what they want to do. Or what they want us to do. Is there anything else here? You guys want to add to that list. Yeah. I send you an email. I hope you would give me some feedback. One topic that is of interest to me, I don't know if it's of interest to anyone else, but it's because I'm working at a software service company. And before, like, look at function as a service in one way, it's going to, it replaces that they would show machines or containers in one view. So you would expect that all the big providers, they offer function as a service and they do. But interestingly, we now there are many, many more function as service providers. So we see people like crowdflare doing it and Adobe, but we also see other really focused up as a services or platforms bring their own function as a service, like 2,000 of zero brain tree from PayPal. We used it last for two weeks ago. So what's really interesting now is that even if you choose a single cloud provider and then you choose a few external services, you may end up with a couple of function as a services that you actually use. And that's not something you would have seen before. So I think that is really interesting and it also makes the serverless landscape different than containers because like of zero or two, you wouldn't expect that they host containers, right? But they host functions. So we could kind of state that, talk a little bit about it. We can talk a little bit about what the challenges are probably going to be, like how do you understand your whole system? How do you keep metrics, other words, blogging, right? And then turn that into a question for the birds of Peter session. Because I also think there is potential to have a somewhat standardization because Mike, I was never in a position to do that, but I guess once you have like three, four, five different function as a services that you have to deploy to and that you have to code with, that will get kind of messy if they're all different in the implementation details. So that's a topic that I can offer. And then, right, that can be extended in talking about service or functional services as a whole. Okay, I'm just trying to take some notes here, try to write down what your ideas there. Go on that. So I want to make sure I got this right though, because it sounded interesting. So it sounds like you wanted to potentially offer some advice on managing the functions themselves and how when you start managing lots of them, the role of standards may become more important to you because you didn't get any commonality across them. You don't have to treat each one separately. Is that, am I summarizing that right? Well, basically, I've said as an open question. So, how would I say that? So right now, for example, off zero, they offer their own functional service and it's really tuned towards their API. So, which makes sense in some ways, but then it comes with, I mean, the question is how much can you standardize maybe, but at least around deployment and so on, you could standardize a lot. So for me, it's an open question because I look, I mean, I kind of did the market analysis to understand what we should do. I kind of came to the conclusion that, I would say that if every, I mean, like in this enterprise case where you buy five, 10, 15 different services and then merge them all together and then if you have everyone brings their own functional service, you end up in a really grange place that was my gut feeling, but everyone else thinks it's fine to set up their own functional service. So for me, it's an open question. Right. Personally, I think that's a really interesting topic to bring up if nothing else, just to get the ball rolling in terms of a discussion with the community to see what their experience is. Because people may not, people may think that they're the only ones experiencing these problems and it might be nice to hear that other people are having the same kind of issues and that may then lead to people saying, hey, let's do something about this. Yeah, that will be my hope as well. Yeah. Interesting. Okay, I like that idea. Okay. I mean, you can also approach this from the other side from the software as a service platforms because for them, it is really, really hard to, that's kind of what I try to do. It's really, really hard to reuse the functional services that are provided by the cloud vendors because everyone brings their own interface and so if you want to integrate with three, five, 10 different cloud providers, then your customer side is much more trouble for you as software service provider than just going, setting up your own. So this standardization could also happen on the other side like we sort of do with cloud events now. Yep, that makes sense. Okay, yeah. Anybody else have anything they want to mention relative to the longer serverless working group session? Doug, do you envision someone opening up with say 15 or 20 minutes so that state of how do you make sense of all this serverless stuff and then opening up to a bunch of other conversation? Is that what's in your mind? I think so, yeah, I think I was hoping at some point someone would volunteer to say, okay, I'll summarize where the working group thinks the state of serverless has evolved to since the last time we produced the paper and talk about potentially what changes we've made to the white paper and landscape doc, as soon as we have made any or maybe we haven't and they just talked about in general where the industry has changed from our point of view. And then, yes, turned into a bunch of other interactive discussion with the community. If that makes sense to you guys. Doug, I'd also be interested in trying to help update the doc. Okay. Cool. Was there somebody, Chad, were you asking because this is something that you'd like to sort of leave the discussion on in terms of the state of the environment? I could, yeah, my attendance at KubeCon is very up in the air at the moment. Okay, I'll tell you why. I can't commit at this time, but... Okay, I'll put your name down there tentatively. Okay. So thank you. Actually, it sounds like state of serverless. And obviously, since Kristoff with your ideas there, you probably have a hand in that, at least relative to the discussion starting section with the community folks to start prompting those ideas for discussions. Jude, your hands up. Yeah. I don't know if this is off-topic or on-topic, but I'm going to just put it out there. So for example, when I worked last, we did like an AWS Lambda versus the serverless AWS functions versus our own server, like a stateful server, stateless, like a microservice. And in terms of cost, the microservice hosting like a service is much more cost-effective than using AWS Lambda. I don't know if this works as like, you know, like a use case or like an example or something like that. Hmm. Like it's more cost-effective, at least on the AWS to kind of not use serverless Lambdas, but to kind of host your own service, that's much more effective. Lots of hot nuances to that debate. Yeah, well, yeah, I was going to say I think if it turns into a discussion of the charging model for AWS, that's probably not a good topic, but what I'm trying to figure out is is there a discussion there that says you know, everybody talks about serverless as being more cost-effective. However, there are some use cases where it actually may not be more cost-effective. So you don't have to mention AWS specifically, but you can say in general, you know, but when you're doing this particular type of deployment or type of application, maybe serverless isn't the most effective because of X, Y, and Z. That might be an interesting discussion, yes. Yes, so serverless. So what we found out is serverless when you kind of go to scale and when I mean scale of like say processing like say millions of requests serverless does not it's not really cost-effective. So this is kind of cost-effective only when you're handling a request where it's like, you know, thousands per hour. But when it when like your scale kind of increases really large, then serverless does not get effective at all. It's in fact more I mean, what Now you're making an architectural statement. You're making a I'm thinking of a vendor and their pricing model statement. Because I can very much imagine a platform which can give you a million events per second and gives them to you cheap. Okay, so I don't know. So we evaluated kind of AWS and I see this but that's the point you have evaluated existing products but it's not an architectural statement. Sure, yeah. Yeah, we got to be very careful there, right? Because we don't want to pick on anybody in particular but if we do think that as Clement said, if their architectural things lessons learned that would be useful as long as we're not focusing on one particular vendor to do it. Because whatever the pricing model is is what people can get ultimately that's how the price is determined but that's not truly an architectural concern. The better the infrastructures get and the more competition Lambda gets the cheaper stuff is going to get and it's always that way but that doesn't change the truth of the architecture. Of course, yeah. I was just mentioning this from a current state of how it's priced across vendors. But if you can find I do think the general topic is probably a good one to bring up because I think the entire question of when to use serverless versus paths versus containers of service I think from my personal experience I think there is still some confusion in the industry in terms of people knowing when to choose what or do they even need to think about it with something like K-Native the line between all three of those are very very blurred to me as an example. Does it really matter what you call it? You're just using this piece of technology to host something but I think people are looking for some sort of guidance here and if we can think of something to say in this space to help make them feel more comfortable with their decision making I think that would be good. I just don't want to pick on AWS or any other vendor to make it happen. Which kind of use cases are appropriate for serverless versus like a pass and so on. What's interesting is we did talk about this in the white paper already and so I don't want to, I don't think it needs to be right for us to repeat everything we mentioned in the white paper but if we could sit there and say the white paper gave some high level guidance on when to use all these things but in practice this is what we found out or our experience has given us validation for what we put in the white paper is correct so if we could talk about our experience in general from an architectural perspective about when to do these things I think that would be very useful and then that could get a discussion going with the broader audience. Yeah and this might also be touching upon a broader topic of what are the use cases for serverless. It always comes up when people always ask me what can you use serverless for and my answer is always it's just code there's a million things you can do but I'd love to hear from the community what people are actually doing and have people talk about their experiences as a way to share what's possible with serverless and where to get started. Yep. Just taking some notes here. These are all good things at some point what we should probably do is if something else just come up with a list of these questions that we want to throw out to the audience and see what their experience is and if no one answers it then obviously one of us can share our experience with it just to get the ball rolling but having a list of questions for the B.O.F. would be good and I think we're starting to get a good list here already so this is all good stuff. So there's that side breakout serverless conference next to Kubcon I don't understand the exact timing of that event. I don't know either because the last I've seen is they have that document sort of lays out the general idea and they talk about some sort of committee doing it but I haven't heard about the next steps. If you want I'll take the AI to go ping Chris Anacheck to see what's going on with that thing. Yeah it would just be real sad if like the birds of a feather session got scheduled the last day which conflicted with the serverless summit as a breakout conference. Yeah. Okay I'll take the AI to ping Chris and find out what is up with that. Okay we'll do. Or like should I stay an extra day and join that too because that'd be interesting for I can't remember did that document even say what day was going to be or just that they want to do it during the conference at some point. I think they just wanted to do it but they want to do a whole day which doesn't make sense if you're traveling for a KubeCon and then you're being asked to divert to a different conference. Yeah. Okay I'll ask them just to see if they have any more details and things like which day after or before kind of thing. Okay topics. Yeah because if it's a direct overlap well that's the other thing it's not clearly for example whether it's going to be just sessions where people give just like it's a KubeCon kind of conference or whether this is meant to be more of an interactive discussion among the community like a gigantic B.O.F. because if it's a gigantic B.O.F. then are they duplicating what we're doing? Exactly. And if that's the case CNCF serverless workgroup should definitely attend in some fashion. Right. Okay. I've totally got these things mixed up actually. I like merged them in my head I think. Yeah that's a good thing we're bringing it up then. So thank you Scott for the sessions or more B.O.F. like. Okay. I'll try to get more information on that. Alright. Okay anything else relative to any of the sessions you guys want to talk about because I have a feeling right now we're kind of at the point now where anybody whose names are signed up to these things they need to sort of take the next step possibly flushing it out or flushing it out. Okay. Sorry flushing it out. And taking the next round of something relative to it to make it more a little more real. You guys think we need to meet again next week or I'm waiting a little bit towards waiting a little while because it's not till May. I think the one thing that may require a little bit of work relatively soon is to potentially updating our landscape in doc. Where's that hosted? It's on the service working groups GitHub repo. Okay. Thank you. Yep. Is there somebody on the call who wants to take a first pass at looking at what's there to see whether they think something needs to be updated not asking you to update it but thinking whether there's something or doing the analysis to see if something maybe needs to be updated to names were mentioned. What? Yeah. I need to go read it again and see if it still resonates or if it's like out of date. Okay. I'll tell you why I do this. I'll poke Dan as well since he volunteered to completely on his own to say he wants to help there. So between you and Dan maybe you guys could take a look at and see whether you think something needs to be done in that space. So we could then figure out how to make that happen. Not necessarily saying it's you guys but just we'll figure out who does the work then. Yeah. Is that Mr. Barker? Yeah. Dan Barker. Yeah. So what do you guys think about maybe not meeting next week but maybe in two weeks? Yes. Does anybody think we need to meet sooner than that for any reason? Okay. I'm not hearing it. Okay. So same time, same place after normal call in two weeks. Okay. Anything else you guys want to talk about? Anything we're forgetting? All right. In that case, I think we're done. Oh good. Cool. Thank you guys very much. I think we made some progress here. And Doug, I will promise that tomorrow I will do a lot of homework. I appreciate that. Thank you very much. All right. Thank you. I like that. Okay. Thanks guys. See you later. Bye guys. Bye.