 Tommy Chung, hello, Eric, hello, I'm the chair today, not voluntarily, but Doc made me. Well, this will be interesting to have a different perspective on it though. I'm sure you look great. Hey, Clamans. Ooh, we have shiny and very crisp screen sharing again. Oh, yes, and that is because I use windows. I mean, I don't know why that is. I hope nobody ever takes me seriously when I praise the products of Microsoft that I'm not involved in. To be fair, the surface book are awesome. Yeah, they are. I have the surface to the surface book to and I'm super happy with it. Ainsley. This is actually ginger. Oh, yeah, ginger. I have got to figure this out. That's right. I think Doc made the same mistake. Yeah, it's really annoying. No change. You can rename it. So Zoom gives you the option to click on your name on the participant's list and rename it. So that's what I have to do every time. It's just annoying. Yes. Hello, Hines. Hello, hello. God. Varun. Howdy. Vladimir. Good morning. Matias. Good morning. See, I know how to pronounce that. I have to leave early today. That's okay. I think this will be relatively short because we don't have a lot of PRs. There's one ongoing discussion where I'm not sure that Alan is going to show up, but I can probably talk to it. Klaus is here. Hello. And there's someone on the phone. 925-699-0277. Good morning. This is John Mitchell. Okay. As I said earlier, Tim, Doggy has asked me to take over the chair for the day since he's out. And I was not in a position to say no. I'm just thrilled that you got here, Clemens, because otherwise I was up on deck somewhere, like number three. I would have been number two. Yes, that is true. And the only reason why that is so is that there was a, I was supposed to be on a flight in a Zeppelin, but the weather is bad, so they canceled it. So that's why I'm, yeah. But now I have the pleasure to spend time with you all, which is great. Matias, Matias, you're doing all kinds of things there that allowed you. Sorry. I think the rule is waiting until three minutes after the hour. So we'll do that soon. Gabrielle, Daniel, Marker, I'm here. Hello, Kristoff. Hi. Hi. I find typing in front of so many people frightening. Well, I should be doing more demos. Tim. Yeah, the demos at KubeCon were super fun. So if you click on Bear Burton and then you can see turn off print mode. That'll collapse your document. Turn off print mode. I can, I barely, so I don't think I'm even editor in this thing, so I can probably make a proposal and then someone has to go and accept it and I don't want to break anything. I'm just, I'm just going to go and make annotations in this document, which will later be accepted by someone and then hopefully I don't break anything. All right. So, but I hope you can see. So Doug is out right now. I'm not sure what he's doing, but he asked me that I take over the call for this week and I think next week someone else is doing the call. So I think it's going to be relatively quick because we don't have a lot of PRs and we have a few issues and then there's going to be the SDK call. It's going to be afterwards, but so question community time. Anybody have anything of importance to raise? That is not the case. The SDK subgroup is going to meet after this call and probably within this hour if we're quick enough. But the incubator proposal, I don't know. I don't know what the status is of there. Neither do I have insight into the KubeCon proceedings and so we should proceed to PRs and issues. There is Tim provided an update for the, this is relatively new. Did you just, did anyone just ask that? I added it. It seems to be just a correction of an example. So I thought it might let's go and let's go and take a look at this because I've seen it and you just, okay, so you just added this hour ago. So formally that's too late, but I think Yes, I think we usually wave through PRs that are just corrections of some text. Yes, we do. So change here. Do you want to talk about it? Do you want to say what you fixed? I just added it to the document because I thought it might be discussed today. I'm not the one who created it. Oh, okay. Yes. I don't know if Tim is in the call. So Oh, sorry. Yeah. Okay. He might not be okay. So, but I have commented on this. It's relatively easy. We have effectively a leftover in the average document is that data is represented as base 64, which is senseless in Avro because Avro understands bytes. So it just changes that to something that makes more sense. Now we can make this a little bit more complicated, but that's what the correction is. I would not take this right now and it would still come in because data content type, this should be data content type. And I would probably go and refer if this was not using the content type at all, but would use it something that's the data field would have a simple value. So I would, I think this is a patch that we should take personally, but I would not take that right now. Comments? No. It's been too late. So let's go and take this next week. So that was the, that's the only PR I think that's in the list. Let's go and take a look at the list per se. I think there's anything that's, this is a new one. This one is, is one that we're going to talk about in the SDK call. And this has been discussed with Alan is not here to defend it. But let's take a look at this briefly. So what this, so Alan is not here unfortunately, but I've been in that discussion. So let me, let me try to explain that. Effectively, we have not made clear that the context that all context attributes need to be of the, the inside the type system. And Alan has been concerned because that is missing, specifically for extensions that would cause interoperability issues. So this is effectively tightening up that text. That's the goal of this. And then he also clarifies, and that's something that I've been, that has been, I think explicitly clear that we have this canonical string representation, and we must be able to convert to it from it. So he's now adding this text. So I think the rule, the, the thing, I think the rule that he wants to add here is effectively the extension attributes must also adhere to that rule that extension attributes specifically also must follow the canonical string encoding to avoid ambiguity with other string encoders. Personally, I don't have a strong feeling about this comments. Anybody has thought about thoughts about this? Does anybody think that this text is improving on what we have or helps with interoperability better? Christoph? I don't see so much what it adds to be honest, but it doesn't make things worse, I guess. So I don't really have an opinion. Scott? Yeah, that's correct. So the, the, I think, I think the journey of an extension attribute is that it may start out as a native integer in, in AQP, and then if it gets, if it gets reserialized on, on a, on a route, it may hit a transport where, or format where it must be represented as a string, and then it gets turned from the native representation into the string representation and it stays that way. And so what bad, what bad thing would this language prevent happening? Because I can't think of any. Yeah, neither can I. Because I think possibly maybe the, the conical form is the, the type that's safe to go into headers versus what's acceptable to go into JSON versus something else, non, non-escaped string, potentially. So let's, let's see what, what fixes 508. So, so I think his point, his point was in the beginning as we started this discussion is that interoperability isn't possible because the extension is not, the, the extensions are not to, not defined to be within the type system. And I think that's the, the, the goal of the fix is to make sure that they are. And I think that's the, that's the objection that he has. But since extensions are just context attributes, I'm not sure that that's true. Okay. Once again, it would really help if somebody could explain the problem as fixes and how it fixes it. Yeah. I would see where to go to table this one. Because I think Alan needs to come up, if Alan cares about this more than we seem to seem to, then he needs to come and defend it. Agree? I think the first line kind of makes sense. The first strings or context attributes must be one of the type listed. I mean, it already says that, but, but the rest I, he really needs to go and explain it. Yeah. Okay. So yeah, I have no problem with this, but let's go and make this part of the, the review then next, for next week. Perhaps someone could make a comment on the PR asking for clarity of what's being fixed. That'd be great if someone could do this. So let's, wow, how do I do that now? Oh, the link to his PR is already lower in the document, actually. Was it? Oh, all right. Great. And then that's also from Alan. There's another thing, which is somewhat unfortunate that he's not here. Yeah. Since we got rid of data content encoding. Oh, okay. So that's already closed. Okay. Sorry. Closed. I had a question about data content encoding. Yeah. If, let's say you're trying to translate a, an HTTP structured encoded message into a binary encoded message, would you expect for, for the body to be base 64 encoded and then have the normal header set or, or is that not a concern? Like if you preserve that for that translation. If you go from what, from structure to binary? Yes. If you go from structured with a data base 64, that goes via the, so it's a binary. And it's treated as a binary, which means that database 64 goes as binary into the entity body of the HTTP request. Keep it, do you keep it base 64 or do you? No, you read it. So, so basics, we have now made basics before a, a feature of JSON. So underscore basics, the force of, is a feature of the JSON binding, which means as if you read it in a underscore basics, the force effectively a flag, it's a, it's an attribute, if you will, on the data field that says this here is JSON and this is JSON string, but you ought to treat it as a binary. So you read it in and it becomes a binary in your in memory structure, whatever you use. And this is, if you turn that memory structure back into an HTTP request, well, then you just sterilize the binary out as binary. So the base 64 goes away as you're, as you're deserializing as the, the event. Okay. Okay. All right, that sounds good. So let's go and take a look at issues that were open. There's one issue that's also theorized by Allen, which makes it even sadder that he's not here. And that comes from, so this is the issue from Tim that Tim is trying to fix with that PR. And now we have affected two things which are related. The inconsistency integer type mapping for MQP. We explicitly define our integers as having 32-bit range, which I'm going to go in, we're going to take a look at that in a second. But the MQP spec maps to MQP long and that is 64-bit long. So arguably the MQP mapping is too wide in numbers, in terms of numbers and bits. And then, and here, and then Allen raises this, says, because we're now going to 1.0, he just wants to make sure that that we're addressing this. The C spec uses 32-bits for integers. So those two things are related. If we make the range bigger than the misspatch with MQP is gone. So he's like, shall we make this 64-bit? So let's take a look at that briefly. Here's that. So I think what's being raised here is the question of, since we're not talking about bits here, we're, well, actually we say this is within the range of assigned 32-bit, 32-bit literature. Whether we shall expand that to 64-bits, whether we shall leave that at 32, does anybody have any feelings? Yeah, I think it would probably be dangerous to extend them to 64-bits because a very high proportion of the data shuffling back and forth around the internet is in JSON. And in JSON, the only thing you can expect to be interoperable is 64-bit floats, which means you really only have 53-bits of integer. And essentially, if you require it to support 64-bits, that means you probably can't transmit it in JSON unless you encode it as a string, which is icky. Tim, I would like to go on a world tour with you and start limiting JSON from the internet, but it's probably not going to happen. I like JSON. I wouldn't do that. No? Well, okay. I think it's terrible. Anyhow, you really have 64-bit integers if JSON is a first-class citizen. That is the truth. Anybody have dissenting opinions? I think before 1.0, we should minimize the amount of such changes, so I think we should stick to 32-bit. I agree. I'm not sure how to add links to that thing if I can. Issues. Let's do this like this. Oops. 64-bit to first key because timing and JSON support for inverse. Okay. And then I don't think the mapping to NQP long hurts because NQP is actually pretty clever about how it encodes things. If the number is short, the encoding will be shorter. That's mostly between Al and me, I would say, for the NQP mapping. I don't have any problems with the issue that he raised there, so let's go and also make a comment on this one. Unless someone wants to speak up in favor of clipping it to an int. Anybody wants to speak up in favor of any of the issues that are here? Good. Well... Just a formal question. Is the mapping thing somehow a v1, version 1 issue? Well, I think bits with bit sizes are something that's a decision that's pretty heavy in terms of you know, back and forth compatibility. You can always go longer, but you can't really go shorter. So, yeah, I think that's a thing that Alan raised specifically and he called that out. He said, this is something we should just go and discuss before we go v1. And I think we just did that. Okay. Anything else anybody wants to raise? No. Good. Well then. Then I have a few people that I think we're done then. There will be an SDK call right after this. If everybody is here for the SDK call, which kind of seems like we can start that right away after that. Otherwise, I wish you a great day. Christian Laxina joins. Hello. You got my name right. Thank you. Hello. And then Alvin I've seen. And these are, I think this is everybody who has captured. All right. I think that's it. So thank you very much for showing up. And the next meeting, we'll have a few people missing because there's a holiday in Germany and doggies are not going to be here, but we still have business to close out. So you should nevertheless show up even though some of us are not. And that's it. SDK folks, just stay on the line, I would say. Or if you insist that we do this in half an hour, we can do that too. I have to say these calls feel a lot less, a lot more formal when I'm not running them. And that's not because of Doug, but that's mostly because of the missing separation between writing and talking. Did Doug give you his gavel? No, he actually contacted me over Slack and said, you're going to do it. Well, no, he asked so nicely that I couldn't say no. So there is no gavel here. All right. Scott, so do we feel we need to wait until the top of the hour? Or do we have everybody we need? I think. I think we have the crew. I think so too. Great. So Scott, I have now done the homework and I've read through your amendments for the SDK documents. I'm sitting down. And I have no objections. I think this is good. Oh, are you feeling okay? What? I think that's fine. That's a pretty view. Now, let's see what does the red mean and what does the green mean? I think yellow is a diff. Red is deleted and green is added. Exactly. So I don't disagree with what you wrote. I just feel like it's hard to be this prescriptive for every language that we may want to use for cloud events. Yeah. And so I've done a little bit of go exercising between whenever, well, you know, because my scope in that work is growing a little bit. So I need to be, while I will not gain proficiency, probably I should be able to read the code well. And so I've been taking some courses, et cetera. So I now understand better where you're coming from. And so it's definitely a slightly uncomfortable from like the Java world where everything needs to have setters and getters. And you're like, what do you mean I can just reach down in and modify stuff? It's a language. So since I've been cursory, I've been reading go code for a while, obviously, but now I've actually went in and did the proper course in it. And it's clear that this is the revenge of the C people for C++. That's what it looks like to me. And so it has a lot of, it's very C-like in the original sense of like the unpolluted original sense of C in a way with lots and lots and lots of modern elements and more safety, but it clearly has a very C feeling to it. Like from when I first learned C, that seems like a very natural upgrade path, also from a mindset perspective, et cetera, and kind of fixing all the problems that C had without going through the terrible, horrible, thicket of barbed wire that is C++. Yeah, there's a Twitter joke right now. People are looking at making go plus plus. Oh, God, no. So I actually have, I've been working on the SDK this week. I've done several PRs and I now can produce most of the 1.0 spec. Sorry, I'm getting distracted. So reword the SDK. Looks good. Sure. Let's merge it. It's great. Yeah. For me, that's fine. That's fine as it is. And does anybody, I don't know, does anybody else have opinions about this? Did anybody else read it? All right. Does anybody object to merging this? No. Well, that's good. Then I think in drafting this, I realized that the go lang SDK needs to have some adjustments, which Alan and I are actively working on. Okay, great. So record it that. Let's go back here. Because I think that's in terms of SDK-related documents, that's the last thing that we have. So we're going to go and do this and I'm going to take mine. I'm going to do that immediately. I'm going to close that one. Good. So amongst the coders, do we think we should do a cross SDK code review effort? How do we think about that? I would love to know how other people are having, like what the experience upgrading to 1.0 has been. Are there any other active developers that are working on SDKs? I know, Clemens, you've done this. Yes, I've done this. So for me, it's been fairly uneventful, except that I've been doing a bunch of conditionals around some constructs, because we made some changes towards 0.3 that were structural. And then we started cutting the map support now towards 1.0. And I think that was the biggest significant change. And then we had also rules around simplifications around data content type, et cetera. But I didn't have anything that really stuck out as a giant issue. What I've been doing in the SDK is basically allow for in the strongly type representation of the event, there I'm effectively tracking the latest version. And that's what you need to program against. And if you want to go and this is kind of towards 1.0, you know, you pick the SDK and the SDK has a particular version that it is biased towards and you take those bits and use those. The internal core, so I have this class called the cloud events attributes. And that's the thing that does the serialization and does the validation. That thing just operates on a dictionary and that thing then gets kind of loaded up, if you will, by the strongly typed shim that's around it. So I've been doing like all most of the upgrade work happened in there and I didn't find, yeah, for me, that wasn't very complicated. It was mostly just, it was a cutting code in the sense of, you know, stashing it away if it's not 1.0 rather than rather than making anything more complicated. So I think we've been doing some simplification work here, which has, which is helping. Actually, so in the primer, there's a, there's language that says the specification places no restrictions on the type of extension attributes, meaning they may be simple types, strings and integers, complex, structured, or undefined collection of attributes. How about you follow PR to go and fix that? Yeah. I've been highlighting things that I need to follow up on. So I have several things that I've found that are slightly inconsistent, but I'm, this, this is incorrect, right? Like we don't allow multi-level extensions into the payload anymore, or sorry, not the payload, the attributes. I can't say like food.bar.baz is a string. No, you can't. And, and that's the, I think that's a leftover. So this, I don't think anybody has, has paid as close attention to the primer as we should. And I think the primer is also a document where, that is the most patchwork. So one of the things for next week, I think, is look at, so we've, we're within the two week period, I think where we all said that we want to go and take a little closer look at documents. So basically out of the development experience, it would be great to go and make a, take a pass through the primer specifically and see where there's stuff that needs to be patched up. And it could be that there's even you know, duplication between paragraphs or that, you know, one paragraph doesn't really flow with another one. So doing some editorial patches there would be, would probably be helpful. And the primer is the document that is not normative, but it's really just the explanation. And if there's stuff that is just wrong because we've made changes and nobody cared to track them in the primer, then we should go and correct that. That's, that's, the primer is a document also that we can probably keep revising and clarifying beyond V1 because that's not, I don't think that, I don't think that document is versions. The, as far as the spec goes, the only inconsistency I found is there is a must in attribute naming convention. It says attributes must begin with a lower case letter, but they also say that they're case insensitive. Yeah, I think they, I think the rule, the rule is that they all need to be lower case. I think that's what we agreed on. So that, let's, let's go and find that. Oh, I see. So it's, don't use uppercase letters. Use, don't use uppercase at all because we had this, we had this, we had a debate about this. And because you already get it, get an issue with, you know, permitted, where were we? Yes, must consist of lower case letters and digits must begin with a lower case letter, arguably we can delete because that's implied. Yeah. And my one other thing is I've been calling, you know, like HTTP and AMQP and NAT things, transports, but the spectrum protocol. But I think it mixes the terminology between transports and protocols and transport particle bindings and things like that. Which, which is the preferred word to use. I want to change things in my side. If you, if you aim for perfection, then I think that those are applications. The things we have bindings for all application protocols, because the, the transport underneath is where, you know, TCP or UDP or quick. And then we, we really map to app for the application protocols. They're not really transports. That's the purity of it. But then what they do for us is they obviously act as transports. So I will say in that case, I will say in that case that I'm probably too deep in that terminology hole that I can probably not see clearly what works better for the normal people. And so I'm not going to take a, take a position on that. Why, I'm trying to get the SDK language to be as close to the spec as possible. So I think I'm going to rename everything to protocols and not transports. Yeah. Protocol binding. That's all I have. I'm, I'm still working through it. I think I've, you know, there's a lot of, I'm doing a bunch of casing too, but it's, it's to avoid complicated logic paths because we've simplified a lot of things. So that's nice. Hi everybody. Sorry I'm late. I didn't have the time for this meeting in my calendar. Hello, Alan. Hello. Hello, Clemens. Remember me? Is that me or is that him? Oh, no, I'm sorry. Carry on. I'm no need to. Alan's talking to you, Clemens. Yes. Oh, wait. I have not, I have not, sorry. I had some, I had some network issues or I'm having network issues, oddly, even though this is my house. Alan, hello. My wife is always complaining about the network and she's using our house. Yeah, well, that's true. Oh, so what's about this networking stuff? You're always bloody breaking it. So Alan, we had, what, what did you tell me while I couldn't leave? I was just saying hello. Okay. We, it would have been great if you had been here 45 minutes ago because we had your, we had your PRs on the table or sorry, your issues on the table in terms of business of integer. Yes. And so Tim Gray said, well, we can't expand it to, we can't expand to 64 bit because of the width of JSON, which is something that I think you also mentioned. Well, yeah, it's kind of, that was kind of the opposite argument. I don't really feel strongly about it. I just thought we should make sure we haven't done it, made a mistake before we go to press the width of JSON in practice. JSON doesn't specify anyway, but in practice, it's the width of the integer part of an IEEE 64 bit float, which is about 52 bits. Yes, Tim, Tim mentioned that, he mentioned that exactly. So that's why we didn't take that and for MQP and so the MQP issue that we also talked about that, since the MQP long actually encodes into whatever bits you need ultimately because of the way how the type system works in the MQP, I don't care. I mean, there's separate wire types. There's a short for 16 and in for 32 and a long for 64. No, no, but there's a, but the long actually has a short, has two short representations. Like it actually looks at the value and then picks a subtype that then has the appropriate length. Oh yeah, and has a zero special case and all that weird stuff. Yeah, exactly. It has all that. The longest, the longest certainly able to do everything it needs to be. It's just, the int would do just as well. Yes, but I, so I don't care. That's okay, neither do I then. Good, consider it not cared then and we'll just have to add integer 64 later if we have to. Yes, because I don't think that hurt at all. Good. So we get disconnected or did Klemens suddenly stop talking? I think Klemens dropped for a second. I guess his household network issue. Oh, wow. Maybe it's your video upload speed is not having good times. Oh, that is because Alan joined and Alan has the video on and that's why I'm, that's why I'm getting screwed here because I'm not, I'm not sure what's wrong. I'll hide myself again. That's less fun though. Anyone else want to speak up non C sharp or go laying SDK authors? Are we concerned that the, there's not progress on the other SDKs? I am somewhat concerned. I have to say if it's slow people behind me that are getting nervous. I think, I think product implementation will help there. So if I can assure you that we will go and ship product with cloud events. And then from what I, what I hear Tim telegraphing, it seems like they're going to, going to do cloud events too. And I think that problem would solve itself. The question is whether that's going to be the official SDK for our, for what we are going to do in C sharp. It looks like my engineering team is actually looking at using the, this SDK as the core, which is a good, which is a good thing because then they will take ownership of it because they hate whenever I write code. And so we're probably going to build on top of the, the official SDK for our, for our purposes. And I would assume that in your world, Scott, that's going to be similar. And I think for other languages, for other languages, I mean, we have a, we have a specification that people can build to. And what we've created is reasonably compatible with, with existing stacks that people have so that like, if you want to send an, an, a binary event, you need nothing but a regular HTTP client, right? That's all you need. And that was kind of the one design goals. And you can get pretty far with just having a, a, you know, JSON encoder and HTTP client, which means you probably don't necessarily need to have the SDK for simple cases. So I'm not, I'm not too concerned because I think we kept the spec easy enough so that it's fairly approachable from standard clients. So I'm not too concerned about scenarios with JavaScript, you know, TypeScript, I need to type on of those languages for something that's more, a little more sophisticated and C sharp, Java and, and go and the expectations that developers have, you know, strongly typed experiences, et cetera, et cetera. That's more important. I haven't looked at the Java, at the Java state of the world of the Java SDK. I haven't either. And that's, that's one that I'd be, keep getting asked about. Yeah. And that's understandably. So do, do we know, do we know who, who it's not. Oh, Matthias does. Then we should, then we should start, we should probably nag and see, probably can get some little bit more, more traction on that. And then probably the next one is JavaScript because there's a lot of JavaScript devs. Yeah. Yes. So, let's go and start filing issues and, and deciding those to people, I think, say, Hey, where, how's this going? Okay. Sounds good. I think that's all I have on my side. Great. Fabulous. And I will not keep you longer if there's no other business anybody cares about. And you will all meet next week in here. Well, I'll, me and the other Germans and Doug will not be here. Until then. All right. Bye. Thank you. Bye. Bye. Thank you, everyone.