 Hey everybody So Clemens how are we how is Germany doing in terms of opening back up? My machine was mooted. Hello If you did answer the quest I didn't hear you because you're muted Yes, I have my speakers muted completely. So Hey guys Hello, hey Mike are you there? Hey, hello and Tommy Yo yo Thomas you there I'm here. Hello Hi Hey comments while we're waiting. Um, I'm getting Ping from the CNCF folks who are running One of the conferences in Japan. I don't know which one it is Actually may not be CNCF. Maybe it's a linux foundation one. I don't know one of the guys they keep hanging me asking me whether we want to do a maintainer session Um, and I would say that it's the usual thing, you know, there's a deep dive and an intro I was thinking about saying yes and just um Just doing the intro that we were thinking about doing for the kukai EU um If it's if it ends up being at a time slot that you can make do you want to present if you can't that's fine I can do it myself, but I just wondering if you wanted to be considered to to present if it if the time zone if the time slot works for you So that is all that's all virtual I believe so. Yes Uh, yeah, then japan should work for me because I mean, uh, they are they're not so far off and I mean if they put it into the afternoon, it will certainly work Okay, cool. I thought I would just want to double check. Thank you. Yeah All right colony there I am now excellent. Hello and Eric Hello and ginger Good morning, sir. Good morning you're going yo mark Uh medias, are you there? No, it is It is my apologize. I'm horrible um Manuel Yes, hi. Hello Mr. Scott Negative I have a meat popsicle You have a meat. Oh, what is it? I gotta know No, I am Come on. Oh, I thought you're eating like bacon or something No, I'm quoting The fun movie I apologize. I'm not hip Did I forget anybody I think I got here. Oh, brian Here and also not hip and slightly confused in It's gonna be one of those days. I can tell I just uh It's it's always been a long day for me I'm it Are you there? Yes, I'm here. Hello. This isn't your first time on the call. Is it? No, I didn't think so. Okay. Good. I should have your affiliation them already All right, one more minute and then we'll get the show on the road. Oh, I agree there I'm here. Hello Someone else went flying by uh lance you there Yep, just here. All right, cool I'm also here because I don't know why I keep missing you as you sneak in there. It's not the first time that's happened But welcome And jam. Are you there? I am Excellent A couple more seconds then we'll get started Oh, ryan, are you there? Yes, good morning. Good morning And Tim are you there? Yep Pretty sure I missed it. Oh, I was close. Here we go. T I H O M I R. Got it. All right three after. Let's get this show on the road Um, let's see 23. Okay Um Skipping the AIs for now community time anything from the community people would like to bring up. That's not on the agenda All right sick update no update as of right now if anything happens there. I'll let you guys know Um sdk call so we do have a call after this one Just let you guys know who would normally join that I don't believe slinky is going to be able to join us Just so you guys know I think some of the issues may revolve around him So those would have to wait But we can still see what's on the agenda All right workflow Timmer, would you like to give us an update anything exciting going on there? Yeah, sure. Uh, we decided money and money and I would switch so yeah money will go ahead. Sorry. Okay Yeah, we we can alternate on that So, yeah, uh, we got a rapport from the scenes here. That's nice, but we're still waiting on the sandbox final decision of becoming sandbox project We also had another primer call last monday and we have our next community call next monday. So Gently remind us of that All right any questions for those guys All right moving forward then. Okay before we jump into issues in prs Is there anything hot on the agenda that I forgot to add people want to mention? All right in that case um couple Hopefully smallish prs. I believe this one's mine I just noticed that subscriber or advanced subscriber is actually not used in the spec right now This is in discovery. So I just wanted to do a little cleanup to remove it Obviously, we can add it back in if we do want to talk about at some point Any comments on that? Okay any objection to doing that? All right. Thank y'all Sorry, okay. Oh, wasn't that because of one of the other uh, like the discovery doc? Well, it's in the discovery doc. That's what I that's where I was pulling it from. Yeah You you're okay with that scott? Yeah, that's fine. Okay, cool And I said we could always add it back in later All right at point is to see this one. I believe is strictly syntactical in nature um Actually, I'm sorry. This actually does two things um, this cleans up Actually, this is kind of odd Oh, I see what I did. I apologize. Yes. So for the most part what I was doing here was on Certain terms. I added a pointer to the cloud event spec if it's a duplicate definition from that spec um, I tried to make sure the text is the same, but I also um added language here that talks about how um, if it is copied from that other spec If for some reason there was a difference between the two definitions The cloud event spec takes precedence in terms of the definition And the reason this jumped out of me is weird is I forgot I actually did some Reordering of the terminology itself. I decided to rather than the ordering that was there Which looked a little bit random to me and I apologize that it wasn't but it looked that way to me I tried to make it in the order of From the server back to the client's perspective So you start out with service and source producer intermediary consumer kind of thing just to get a little bit of a flow there For I thought better understanding, but I think that's about it now I had to fix the link checker to to catch that new this funky formatting thing I don't think there's any semantic change in here. It's more syntactical Mainly just adding these little pointers to the cloud event spec Any questions or concerns about that? Any objection to approving? Okay, thank you This one And I actually should apologize for this. I should have actually done this before we merged the other pr for the provider service change This actually just goes through the rest of the spec and gets the other provider uses to usages and converts them to service Strictly syntactical change, I believe. I don't think I did anything with semantic change Unless I just really screwed up and messed up Any questions or concerns about that? Any objection? Okay Thank you All right Okay, I just wanted to bring this to your guy's attention Because slinky pointed or pointing yesterday to mention He did update this pr I think he updated it a couple of days ago though 23rd. Yeah, I can afford to be there. I guess three days ago So technically it could be reviewed and voted on today, but I don't think anybody noticed So I wanted to bring it up to everybody's attention today to take a look at this when you get a chance This is a change I believe in the cloud events space Just wants to add a streaming proposal for Jason. So take a look at it when you get a chance We'll talk about it on a future call. Obviously if you have questions or comments go ahead and mention it in the pr itself Okay, but he's not on the call to take any questions, but I guess if someone wants to raise one right now You're welcome to and maybe someone else can answer it Okay, so that was just an fyi kind of a thing. All right Clemens since you weren't here to Introduce your spec. Is there anything you'd like to say here on this pr? Because I think there's just some outstanding Things that need to resolve first before we consider emerging, right? Yeah, yeah, there are there so I mean I'm expecting there to be a few more rounds of discussions that I've refrained from updating the documents before this call because there are outstanding questions and I want I didn't want to override them With you know, then you know, it's easy to lose track on github. Once you do significant changes So I want to do it. So I acknowledge I acknowledge things that where I'm going to make changes with your thumbs up and More many of yours and then I made some further comments um, so Yeah, this is what this does is in fact, it takes the proposal that I wrote up in the issue and turns that into a proper document And really what this is it's a somewhat smarter version of a plain File store if you will for schema documents So the idea is that schema documents are typically Text text documents some schema formats may be by but they're of the rarer kind and This basically has a structure Where you have a schema group Which is a Organizational bracket around a set of schemas that are typically belonging to an application or to a particular topic And the reason why the schema group exists We're deriving this from from so this this this proposal doesn't come from thin air We actually thought about Implementation pretty hard. So the schema group exists effectively as the top level grouping for creating access control And also to create, you know, a notion of separation in a global registry For applications that potentially even tendency And then inside of that schema group we have schemas and schemas are That They can be concrete. So I have a note in here at the start and then we should go probably go and take a look at the note first I have this if you go scroll a little bit further down There's this note So there are two ways and I've implemented effectively both of those ways in this proposal and they can go together But we can also just opt for one where Either there's two ways to look at a schema. You can go and look at the schema as a concrete documents and basically have a schema for I'm going to make this Let me make this concrete. So you have a schema that is for storage events Avro So then you have effectively an avro schema document that that ever schema document is being stored and versions as it is And that's the simple the simple way of of dealing with this where you Just store effectively under a schema group you score Store schema and the schema has a particular is for a particular format and then you version that The other way of doing this and that's also in here is to say to be truly restful And restful really means that the representation that you can have an entity and the entity can have multiple representations so The entity is really an abstract concept Where you have an event Of some or the body of an event in our case Of some sort But that body of an event can really is an abstract data Data structure and that data structure can now be rendered in multiple ways So it can be rendered in json. It can be rendered in xml. It can be rendered in avro. It can be rendered in protobuf And so schema in that in that view really represents the abstract data structure And so instead of of managing documents You're really managing managing the schemas that define the representations of that abstract data structure And the abstract data structure is the thing that gets versioned here. So the abstract data structure is something that exists Not in this registry, but exists effectively as a document somewhere else And here you're just managing the the the the the schemas that belong to it So so in that way so in that in that in that world And this is case one here It's a truly it's a restful service in the sense that you can go and apply multiple schema documents Which means multiple representations or or meta meta Meta descriptions effectively of a data structure under the same version Where you simply are doing a put on the version number with a content type of Um, you know for the appropriate media type for the jason schema the appropriate media type for an avro schema The appropriate media type for an xml schema and all of those under the same version describe the same exact same data structure So that you can you can then from a um if you want to go and fetch an avro schema you walk up to the If And then you submit the accept header As you're doing an hdp request Where you say these are the schemas i'm willing to accept here And then you know by your order of preference You're going to get the best matching schema back and then you know what serializer you need to You need to load so that then everybody can go and understand The the respective message So that's that would be the truly restful way of of of making a A schema registry, but it's a little bit more complicated So what i'm trying to do here is to You know satisfy this A little bit more isoteric desire for having the ability to to represent a abstract data structure in multiple ways but kind of in multiple formats And store the schemas All alongside under the same version version number And also satisfy the much simpler need of just storing You know a sequence of documents That are describing effectively just one format all all together and We're still debating so on in microsoft. We're still debating on on which of those two choices are the is the right one And so I just included those in this Right up to You know drive the discussion and to say you know we can we can do both we can do the simpler thing And so kind of with that introduction of of what the motivation here is that's what I would like you to You know to use as an intro to go and read that document and see whether that's whether the more complicated the super restful way is I'm far too complicated for implementation because that's ultimately what what the The make or break here is is whether that mechanism whether the mechanisms that are described here are you know practical practical for for implementation What I don't have what I didn't put in here Our hard are too many hard rules. So for instance When you are creating a new schema You can basically just come and and Come to this registry and under a schema group You can do a post um Or sorry, you can do a put with just a schema name and then a new A new schema basic or actually you can do a post Under the screen under a schema group with a new schema um, and then and then it will go and and create the the The first version for you and then you can go and walk up to that same Schema node and you can go and post a new version And it will go and create a new version for you and will store the latest version under that new under that new schema number Under that new version number and if you do a get Just under that schema name you're going to get the latest version So there's a fairly simple way of doing those things you can now in an implementation You could enforce start enforcing rules and have some configuration on the back end that says well If you're adding a new version of the schema Then the configuration says that you have to be backwards compatible with the prior one, right? That's some schema registries have those capabilities that You know you store an average schema and then you store the next version of the average schema And there's a policy in the background That will enforce That that compatibility is there That's allowed here and there's even a You know, there's a explicitly in the in the accompanying Open api definition That you can then go and return a 409 conflict and say, you know, that's not for us But the schema registry per se this definition here doesn't say what that should be Doesn't doesn't see what those rules should be because the rules can be Different depending on what the format is and it's also not constraining which formats you can store So you can do this for avro. You can do this for protobuf and if you have some Other schema formats including xml or something else that you want to go and store the store in here That should also work. So that's the goal of this is to really have a very very open base spec That can accommodate whatever schemas you like and then Um, potentially in an implementation note, um, you can go and constrain that further and say, you know, here's my My avro lens on this So that's the idea behind that specification. So our goal is that the universal interface For a simple as possible, but then as flexible as possible schema registry that everybody can easily implement Hey, and john your hands up Yeah, so, uh, clements are you when you're talking about supporting, you know multiple multiple content types Are you Like how is that being managed? Like are they are you saying that I'm going to build the protobuf version of the schema and the avro version of the schema and the json version or whatever and The registry is just going to accept those and assume that they're the same Yes So so that you you're going to met. So if you want to have multiple representations Then you're going to walk up to the registry and basically just store them under the same under the same, um version So any incompatibilities or things like that when you're talking about, you know, multiple versions and Skewed them, right? So if I update the protobuf one and now it's ahead of the other ones Like how do I how is a consumer going to even know that? um Because you ought to be disciplined when you when you when you do this. So there's no I'm I'm not this is just the interface And you can go and put a lot and you can put logic at the back Which basically said which basically evaluates the the let's go and let's say you you emit a you have you add a protobuf spec And the protobuf spec is now the first spec that is under version three And now you're adding on avro spec That is also under version three. It's basically you're putting you're putting a new one Then you can obviously Create some logic at the back in in a particular implementation that goes and And basically creates a projection of what the avro of the data structure that the that the protobuf spec describes And then checks that against the the um structure that the avro um Spec describes and if there are mismatches you can go and reject that So there's it's it's perfectly possible to do logic at the back which goes and matches all those things But i'm not demanding here in this in this specification that um, you have to do this So this can be as simple as um a file store that is More or less implemented some logic that that's that's being put on top of a blob store So then I then then given that uh, I'll take the rest offline But given that relative to this spec you should call out that that you know this distinction that you're making of the spec versus you know these other logical um quality of service kinds of issues and in terms of Engaging that You know in in some commentary or something because yeah that that That's obviously a key issue in terms of the implementations and the consumers Yeah, I I I think I've mentioned some of that in the document now. I'm I'm relying on Doug to scroll So I should probably not do that Where do I make a go? Yeah, see that's that's um, um I need to go look myself Um Give me a moment Is it this multi-format section? Yeah, I I have I made some implementation reference um so, uh, so this In under version uh, and uh at the um In the intro Um, even though prescribing the specification and implementation might choose to impose compatibility constraints on versions following initial version of a schema For instance, so then I'm already calling that out there and then we have some of that in the Also from access control for access control rules. I'm also making a comment implementations of the specification may associate access control rules for schema groups um, there was a comment that we should also go and Allow that for schemas themselves for versions potentially and So I've I've made I've made references to implementations in several places. So if you um If you have suggestions for where should be stronger, then I'll I'm certainly Certainly willing to go and make that stronger Okay Ryan, I think my hand was before you and I have a quick question. Um So so comments. I like the fact that for the most part you're describing This is just sort of a blob store with a nice file interface on top of it And and leaving the semantics up to either an implementation choice or if they want to do nothing at all, that's great But then we start talking about the version stuff. That's when I start getting a little confused because Um, that's almost adding semantics. I'm wondering why you just don't say, okay You know, this particular user they own this maybe url or this url's group And then they could put whatever they want there, right? If they choose to use if they only choose to have one url and they just keep updating that one version every single time That's up to them if they want to have multiple versions. It's up to them They just change the url that they do a put to I'm wondering why you decided to add semantics around versioning um Because that is really to accommodate the simple case where you don't Care so much Where you really only what you have like you have a schema and then you want to go and store the schema And then you change the schema changes and you just store the new version of the schema under the same name um So there's no compatibility rules You're okay with breaking changes But then you want to have differentiation between the stuff that you have already sent which means now you have a a You know, ultimately you're you're walking up to the registry. You're posting your schema What you're doing what you're doing is you're you're doing a post you're getting a A url back that is the url that you're going to use and give to everybody and that is going to that is going to have the Version number right and now you're going to walk up to the same to the same name And you're posting the new version of the schema and you get another url back That is the the permanent url the permanent link basically to that to that new schema and you're okay with breaking changes That that versioning Right of of you know just posting the new version um That is making things for the simplest kid for the simplest case arguably Simpler because i'm not even forcing you into thinking the the you know the the management of versions. You basically just get a consecutive stream of history of those of those versions one two three four five just number three You don't need to think about semver. You don't need to think about all any of those other things and as soon as you start As soon as you start thinking about the as soon as you make the version management explicit Arguably things gets get harder for the simple case Okay, I hadn't I thought about that simple case you're thinking about I thought maybe they want to manage the versioning numbers being themselves But okay, I understand uh crying your hands up Yeah, um, I know I made a bunch of comments in the in the pr and I haven't followed up on uh on all of your responses clemen So I'll try to do that this week, but um, I think one big question that I have is like how How standalone do we envision this being? I know this is starting with thought events, but I've seen other folks come in from other groups Interested in some kind of common schema registry um, and I ask that because um, just just in my experience building, you know, very generic You know platforms or or services um It's sometimes useful just to have like a diverse set of use cases just to test the design against so I'm just curious as to what um How you're thinking about that and and how generic you uh envision this being so So I certainly envision this envision this uh to be Broad broader than just the cloud event payload Um, because ultimately this describes a it's a it's a Complement complementary capability to any serialization framework Um, where you need to have where you need to share schemas between two parties and that's true for all of messaging and eventing um, so This can compose with a mqp this can compose with mqtt this can compose with cloud events This can compose with Effectively anywhere where you need to have where you exchange schematized data including htp transfer. So that's how broad I see it um and and that's also Because we have this because it's it's hard in cloud events and generally It's hard to draw the line because what we're doing especially with cloud events with the with the with the transport bindings that we have We're intentionally blurring the lines between you know, what eventing is and what and what message transfers are in general like you have a You have an mqp message and the mqp message can take on a cloud event character because you're just adding the the cloud events attributes to it But it runs for a normal message broker. So it's hard to to draw the line there So I see that here as a as a spec that is is generally applicable or that mechanism is generally applicable for um For messaging in in in general Okay Okay And that's another question. That's also that's also let me let me just add one one more thing. That's also why I think the That this is just for the payload And then this actually hope this this gets integrated um Or complemented by the discovery mechanism And where the discovery mechanism really that's the catalog of the the events that can be emitted That talks about all the various properties of cloud events and then this here is really about the the The schema that we leave out of cloud events intentionally and that is the pay that is the payload Okay, and any other questions or comments for clements? Okay, thank you clements and everybody, please. I mean you get a chance if you haven't already Please read through it and leave your comments in the pr. So clements can try to address them offline All right, thank you everybody Next up uh Jim Would you like to chat about your protobuf? Sure, I was rather hoping clements could use up the whole 50 minutes Well, I'm sure he could if you if you ask him to I'm sure he'll talk about the uh the difference between eventing and messaging Okay, so um I've tried to address some of the the commentary I know Evan Evan have made a lot of comments, which I appreciate and I think I've tried to address um I having had that conversation I think a few points have come up and Some of that I'd like to toss out to the group so The issue of grpc has been raised And yes, that definitely needs to if we want to support that needs to be a different document, but Do we consider grpc to be a transport? I guess that's a question I think I'm interested in clements view on that because it It doesn't really smell like a transport to me, but I could see arguments why we should have You know a spec that might Show, you know grpc endpoints to carry cloud events That's a a question out to the the group if anyone has any opinions on that it doesn't necessarily affect this spec But it's just something to think about um Another question that came up was around the representation of timestamps that I'd used And Doug it might be easier to switch over to the the actual proto spec rather than the Markdown on this You mean down here This this right here. Yeah, so I'm gonna actually view it Yeah There you go. Let me know where you want to go to okay, so that that'll do So When I originally put this pr together, um, I just represented all the attributes as a map. Yeah much like avro does and I was sitting there Mulling over whether that was a particularly Idiomatic way to to do stuff In proto, so I then switched over to this other representation where You know, I've you know explicitly listed the required and optional You know attributes as I defined and then left them essentially a map for any Any additional or extensions? um I'm now toying with going back to the other representation The issues of You know, how durable does this become? You know, I this now would be Something that would only work for v1. Yeah, if we had ever added a new required Field, you know or attribute then, you know, would that indicate? You know a new version of this Schema so I'm toying with the idea of just going back to a straight map of attributes And not formally representing them The question around timestamps was And part of this I think was my sort of speedy reading of the spec originally I'd read the spec to me You know from a cloud event perspective that a timestamp had to be sort of Completely represented including a time zone. Yeah, so I used a native prototype for that but Somebody pointed out to me that the spec actually indicates that the time stamps need to be sent as a An iso string. Yeah And I just wanted to make sure that that was And that's what the spec says. I just want to make sure that's what people Thought it should be Because it again To me, you know, if we have an idiomatic way of sending a timestamp. I am not sure in in a particular format like this why I wouldn't just be able to use A formatted, you know a predefined type for that The other questions I've seen were around my The way I'd address the data aspect Where I sort of allowed it to carry, you know a protobuf message Or, you know textual data or binary data now Again, my understanding from reading the spec is that this is sort of allowed in the spec the spec allows for different You know representations. Yeah, and in fact in You know in the jason schema, we allow a jason object to be data In the avro schema. I think we allow an avro record, is that the right term to be data so Again for me, this was more idiomatic if I have a Event payload, which is actually, you know defined by a proto schema Um, it's much more idiomatic for me to just inject that You know explicitly as a proto object You know rather than externally marshalling it into a string just to be able to jam it into You know the or you know marshall it into bytes to be able to then jam it into you know A byte buffer inside another proto object. It just didn't seem very efficient to me Um, so that's that's really where I stand at the moment. As I said, I'm probably going to go back and switch You know the attributes back to a simple map Where and again following the model if we scroll down a bit more dog Where I sort of come up with this model of allowing all of the Types that we define in cloud event to be sort of formally Carried in proto without losing any of their type information. So, you know, if you had an attribute that was a uri You know, you would put it in a uri Name and so the receiving end would know that that attribute was actually a uri and similarly for booleans and timestamps and whatever so That's really where I am at the moment Um Questions Yeah, so what mic your hand was up first and then criminals will go to you since you came off mute, but Yeah, sorry, I had to rewind a little bit. Um So the question was using a map versus having these types in proto Having these types the way they are now is the right way Using a map to define the attributes would not be protocol buffer idiomatic Um, you know adding Adding new fields to and versioning proto's is a well understood thing at least internally at google. Um, we do it all the time So it's Yeah, I mean, you know having the extensions as a map is fine because We don't know what those are ahead of time, but the things like the id source spec version, etc. Those should be Well-defined names Right. Yeah, that was my thinking Because it just seemed more natural to me as well But thank you for the thumbs up on that. Okay. Yeah, and you know the the um, if you had a you know, if we had a you know Let's say version two as a new required field You know, we would drop it in somebody that's to have the version one their protocol buffer were parsed because Uh new fields that aren't known are just dropped Um, so it wouldn't be breaking unless you removed a field I thought in proso three now the changes were made so we didn't you don't drop unknown fields Or is that still a configuration option? I think it's a configuration option. Um, there are I think the There's a difference on whether unknown fields are made available to you as part of the reflection structure or not Right. Um, so I Yeah, I was gonna say I because we were using a paper we were using proto two and switch to three um, and I think we were one of the You know band of people that was pushing for You know the unknown fields to to be put back in, you know, because it was something that changed between two and three and I thought that was becoming The default behavior rather than a configured behavior, but okay Um, I think I'm not I'm not well versed in the depths of photo It it did raise another interesting question for me though whether These schemers themselves need to be versioned. Yeah, so the the namespacing on the Not just the java package, but probably the proto itself Probably needs to be include a you know the one marker You know so that we can support multiple versions side by side if they change dramatically That was another tweet Okay, comments. Did you want to say something you can't off mute? Yeah, that I think the lengthy discussion that we had about bags is coming back in here Um, because the the we have this we used to have this extension extension bucket um that housed the extensions and then we went back to making everything a flat list And this this brings back the extension bucket which has the with the consequence that if a If there's no uneven support on either ends of um, you know, there's a there's a clouded publisher and the cloud event publisher gives you a is Has a new Well-known property so you know a version 1.2 or version 2 There is an intermediary which has the old Knows the 1.0 schema and then there's a receiver on the other end which knows the 2o schema Then the 2o the 2o publisher would use the 2o proto proto schema Would then publish to the intermediary which is using 1o schema Um, and then would probably go and drop the extra attribute on the floor because that's now sitting at the at the at the at the outer level And the the 2o receiver would not get it That would be a new version of this schema though, wouldn't it if it's version 2 Yes, or you're saying you're saying you add a new I don't know optional attribute. Is that your concern? Yeah, so with with the with with what we did with avro where we're where we're against the against the spirit of avro um, are actually using maps and tagged Tagged attributes, right um You can add a field and that that field will pass through The the the intermediary because it doesn't know it doesn't need to know about an extra field Here if you're making the fields our attributes first class right If you're adding a first class element So you're adding after subject or after time you're adding now Uh, you know the next one Then an intermediary which only understands this schema Will basically go and read the proto event will ignore what's at whatever was extra You will have a deserialized object now, which has which doesn't have that extra information And whatever you want to pass on to the the next party Will miss that extra information that the the client submitted because The the serializer will ignore it So the old the old intermediary will ignore it so I think there's a I know and I think I may have mentioned this in the in the PR there's a halfway house solution where You formally declare the required attributes, you know idea and source, but all the optional ones you just leave in in the in the map Yeah, I think that yes that It grates on me a little bit, but I think that's That's the need to solve to that and I think that would then address your Your concern. Yeah, I I believe that's true because the we cannot add in any future version We cannot add anything that's required right yeah So Jim did you get oh, sorry ryan you go ahead you reach her hand um Yeah, I mean I was just looking at the spec uh, and uh, it does say an intermediate should forward optional attributes It's not required. Um, so that would comply with that I think my my broader question is um, you know everyone put a buffer or solving You know the same or or mostly overlapping problems um should We employ the same model It feels like this is deviating from the avro that the implementation of avro that we already have So I wouldn't claim to be an expert in avro. Um The way I was interpreting that spec is that um From what perspective are you talking about the fact of just having it as a map? Correct. Yeah Yeah, I know I say I mean if we just made it a straight map then, you know, it becomes a much more durable thing It it just seemed odd. You know when you have Attributes that you know Are required and want to be first class citizens that It just sort of Smelt better to me to define them. I mean we define them in the jason schema. Yeah Now missy jason schema is a bit loose because you know, you can just add whatever you want so But we did go to the lengths of actually formally Defining those and defining which fields are required and so on So I I think we already have a level of deviation But Point taken. Okay So what would you would you advocate for just a map or or this would you be happy with this sort of Halfway house solution where we formally declare the Required ones and put everything else in a map Or is your comment more around just consistent approach? But my comment is is more about the whether we want consistency I think you know, there's trade-offs to to all the approaches and it's it's hard for me to to give a hard and fast answer on the fly here Um, I think you know doing that that halfway solution would comply to the spec But I think it it probably needs more thought as to the trade-offs But yeah, I was commenting more to the should we and I'm not saying we should or shouldn't it's just raising the question do we want Consistency across the different You know representations or the different Ways of serializing cloud events And I did I'm sorry Let me shut up and let the other people speak lots of hands up Actually, I think Mike's hand your hand is old Mike. Isn't it? I think yeah, I think So you're you're free to go So I was going to say I mean, I wonder if there are echoes here of some of the stk work now I've not been involved in that a lot but I think there was an attempt to sort of have a consistent programming model for the stks And what those groups discovered over time was that You know when you do that you lose some of the You know the idiomatic nature of the languages that you're working in so, you know, they they've naturally sort of You know gone their own way and made them much more language centric so I I don't know but I suspect having explicit Attributes like that probably is more efficient You know on the wire and from a decoding perspective Yeah, okay, I I'll change the spec to the model of You know required and all the optional stuff in a map And we can readdress it. I did have a question. Maybe for Clemens. Can you comment on the timestamping? I was gonna ask about that. Yeah Um So it's in the cloud event spec itself. I don't know if you want to jump over to that It explicitly says it's a string So am I breaking the spirit of a A spirit of a cloud event by saying I want to put it in a you know in a in a Essentially a timestamp binary field the um the uh I didn't think that would I didn't think that you had to cut it with a string Oh It's it's only so so the the um If you just at the top of this of this of this page. No, no, no stop this specification. So type system, right Each of these types may be represented differently by different event formats and protocol metadata fields So you're okay right What this specification does is it defines a canonical string encoding for each type that must be supported by all implementations So if you represent this as a string, then it must be this That's what that means. Excellent. So I should have just read the document. Okay Yes, it is It is at times a fairly dense Right up. It's a nice piece of work. Come on Pat ourselves on the back Exactly that we all jointly created Okay, running a little low on time here unless unless there's something really major relative to The protobuf pr. I'd like to move on if that's okay So I do want to ask the comment around a grpc. Yeah, so yeah that a transport spec It's a protocol. It's a protocol. Yeah, it's not a transport But what which? grpc So once we've defined assuming we can agree on what a proto format looks like, yeah Um, theoretically then we could define grpc bindings which Allowed for not just proto formats but other You know event formats to be exchanged as well. So the question is where would that Go or is it is it just in a world of its own? From a spec perspective, so grpc is going to be interesting because it's grpc is arguably an overlay over Well, it is actually an overlay over hdp2. Yeah And Defines a way how to well do rpc things So it's going to be it's going to be interesting how we can go and define something that is for cloud events. That's not too constraining That is not just a proto definition because ultimately because ultimately you're you're passing a data structure as an argument for a function, right? Yep, and Um We're also we're also obviously struggling with the the we're now having the same struggle in this project as as exists across the The rest of cncf in that everybody's using grpc, which is a cncf project and then But by default using protobuf, which is a google project Not looking at anybody in particular So it's your comment there that we should stay away from it or you don't see it as something this group should Um Should define Or it's just a new type of protocol binding that we haven't seen before um I think it's a I think it's I think it's Reasonable to go and do a a grpc binding right but by our rules um arguably The protobuf the protobuf binding should be probably be part of a grpc binding because that's the context in which it's arguably only permissible because because of the the proprietary nature of protobuf As it stands if we want to go and play play the police on on per our rules So yeah, I think I think it makes I think it makes sense to to have a grpc binding. I'm just wondering what the Whether there is a reasonably generic way to create a grpc binding for this If I may Regarding the protobuf, I want to say that I mean There's quite some usage of protobuf outside of grpc ecosystem And I think if we split into the protobuf definition of the cloud event Uh, so the definition itself and some grpc efforts uh who In my opinion it would be better because people will come and ask for protobuf definition of cloud event not grpc Relate stuff, but just protobuf It's the first command I wanted to make and uh another one kind of related is that we By we I mean, uh, some forces at puerto and now we're We're trying to kick start the conversation about cloud events streaming And uh, I'm also referring to the licous project that I made and later we started using project beef where we tried to generalize Subscriber subscribe, uh, semantics Kafka like semantics, uh describe it in jrpc And uh, we may also Continue the conversation by merging to because uh, that's something else we're trying to discuss as well Like focus on cloud events streaming Focus on cloud events streaming Gem could could you make it real quick? I mean, did you have the last uh statement? Yeah, no, I I would agree. I mean, I think protobuf me the the format needs to be kept separate from the grpc document because you know, we can send these formats over any transport And I'm I'm happy to put a grpc You know proposal together But I'd rather wait until we've got this one to bed before we do that Okay And with that we only have five minutes left and what I wanted to do I had another topic on the agenda, but I'd actually Saving that what I'd rather do is put claus on the spot because he just opened this one of an hour ago Um claus, you want to introduce this one? Because I think this is going to be an interesting topic that may warrant some deep discussion I want to bring it up sooner rather than later Yeah, exactly. So I mean intentionally put in the the work in progress in the title um Because it's I think it's also depending on other changes that will happen before so it's right now It's the change in the event provider and I suppose it will be probably changed to service or something But um The idea I had and I think Was already brought up. I think by Mike or someone in the original google doc we had There was I think a source pattern field um I did some research on existing concepts like what you know probably from open api and those seem to be based on This r of c i'm referencing here for assault for um uri templates And so um That's the the idea of a proposal to have an optional field that would then Uh describe the uh template for how a source field for a certain service would look like then So one example I came up with is this simple example here in the bottom There are of course a few things you might discuss here if this template format is the right one or um this if you look at that r of c it's also defining certain levels of uh complexity I would say for templates if you If we should restrict it to a certain level In my opinion in most cases even level one would be sufficient. So those are things we might discuss or if it's People think it's useful at all The reason I think this is going to be really interesting is because I think this is going to help shape the Uh, how much automation we'll be able to have right versus have to do user input to get things going and And you know once you have this the next question I would have is okay. How do people know what bucket means, right? Do we need some sort of Schema or something that helps to find what actually what this feels actually mean and that that's going to be even more interesting So I want to get this conversation going because I think this is going to be a good one Yeah, so that's of course a big question if you look at other standards like open api or async api they have their own Subobjects for parameters and and quite a big Well a lot of ways you can define those parameters Okay with about a minute. We have left any quick questions for close Okay in that case um Like I said, I did want to talk about this but I'll save that for next week because I think I have an I might need to write something up to better Express it. I was thinking that those come with those questions Um, any other topics you want to bring up before I go back and do final roll call All right. Thank you everybody. Uh curtis. Are you there? Yum, you're hello excellent. Hello Paris are you there Paris Okay, what about grant? I'm here. All right, cool. Did I miss anybody? I'm sorry. This is Paris Lucas. I wasn't near No, not a problem Like do me a favor. I'm not sure I have you in the attendee list yet Can you just either in the zoom chat or someplace like in this on the meeting minutes? Just give your last name and any company affiliation you like to be associated with Um, the last name is lucas l-u-c-a-s And right Ah, I can spell red hat. Thank you Okay Anybody else I missed All right in that case. I believe this part of the call is done We'll start up the stk call in about a minute or two. Just give everybody a chance to get settled or Hit the facility if they need to All right. Thank you everybody. We'll talk next week Okay Hi, it's bright Yep. Bye while we're waiting. Do we actually have any agenda items? You know what happened did I miss up? Didn't we talk last week shouldn't this be like the 21st? Yeah I could have sworn we talked last week Anyway, no big deal. Do we have any items for the agenda? I might expect a discussion of the typescript repo Oh, we could talk about that. I think we resolved that but hopefully we can talk or talk about that anything else Both javascript and go lang went to oh last yesterday Cool anything else Yeah, we can talk about the python sdk Maybe looking for your viewers Okay All right, give me another 30 seconds or so and then we'll get started All right, let's go ahead and do this thing. All right typescript repo Um, so lance correct me if i'm wrong here. Um, and actually I guess grant to since you're on I believe the current state is technically we agreed that as of right now We do not need it and everybody's going to try to do everything within the javascript repo Um, I believe I did get permission from grants to go ahead and delete it However, I decided to hold off on doing that instead. I archived it just because I didn't want to Delete any issues or prs that may be there. I figured it's easy to delete again later But at least it is archived so no work should go on there um Is that a fair summary grant and lance? So I think that was an accurate summary up until maybe Yesterday morning Uh, there is an issue with um type definitions that we're generating Not really, um Not really understanding certainly js docs syntax and and how putting something that's incorrect So as a result, there's a, um We're gonna move forward with you know, um Adding type script to the existing repository But I would say we still do not need the type script repo that I was discussed before Okay, does that make sense? Well I'm trying it sounds like the net of it is still what I said Even though some of the details under the covers may be different. Is that fair? Yeah, pretty much. I mean well, yes the the specifics of for example having to uh constantly run a build which Was not the case in the um in the sort of alternative that I've presented and that landed Will now need to be the case But if those are just details like yeah, I think I think the the net result is we don't need a type script Um And we're taking steps to make type script developers happy in the current repository grant. Would you say that's fair? Yeah, not my grant. Um Yeah, I think uh I mean with the With the changes we're really just trying to get type script support and I think there's um If it's possible We just To generate the script on bindings We need to by itself using type script files The type script bindings sounds great And I'm yeah looking forward to In order to use type script Okay So as I said, I I I'll keep that around the repo just in case something happens and we don't want to Lose the I think the one issue or one pr this upside. Go ahead, Grant I like I don't think it's worth keeping the detail there's I I know I think I had the one pr and If there's I mean, I don't see any reason I already copied the Um, I can have the issue into the JavaScript repo and so Uh, it's all good for deletion from my perspective. Okay. I will do it then. You don't need to be cautious. Okay Cool. Thank you Any other comments questions on that issue or that topic? All right Anybody want to talk about the z2 deliverables? who Scott looking well for go we're looking for feedback and usage and people finding bugs and issues it's um with with the uh Major version 2.0. We're gonna go back to adhere to strict semver protocols and versioning and fun times Yep, that's exciting There's a couple breaking changes from the previews and the rc's because we at the last minute decided to ship all the the protocol implementations as sub modules so some things got Bumped to a different import path, but the code is the same Now earlier was it this week or last week you mentioned a possible Hiccup with the gomod stuff where we need separate repos. Is that issue behind us now? Yeah, I worked around it There's some automation that needs to be written to help make releases happen a little easier, but Basically, like I go to the gomod community and I'm like, yo I want to make sub releases in go modules for sub modules and they're like, yeah, I don't do that. That's that's scary and So it turned out that the documentation for all this stuff is in go files in an internal Full package inside of the go laying Which I don't understand and it's not published anywhere, which is also fun So basically it's like a gomod is highly undocumented And people are unwilling to go and actually understand how it works Okay Any questions about the v2 releases? All right in that case python sdk Who wants to lead that one? Yeah, so I was taking a look at one of the issues published Um, I'm kind of into the sdk, but they there's an issue regarding it not being very pythonic So right now I'm currently creating a class inside of the sdk Directory such that you don't have to do all this overhead of having to manually create Various marshals and stuff. So just making the entire interface much nicer All right now. It's mostly done. I had just I changed some of the internal classes So I'm currently trying to get the other previous tests to pass So I can post a link I guess to the fork that I'm working on somewhere I don't know how this is documented usually So just a Who's the maintainer of python? I can't remember What do we have over there? um I'm Dustin Yes, I don't think you go ahead. Sorry Uh, well, that's a good question. And I don't know if we know the answer um I Does anybody know a denis matto gone? I want to say he might have been from oracle that may be wrong. Yes. It says yeah oracle there's only 30 something Myths on the repo And it looks like he's the primary developer Then said your initial commit in september Usually I guess And so I don't think there's anybody primarily working on this repo right now Okay, I That's one of the issues like in terms of Our view process and developer process getting some feedback from other folks that might be interested in using python As far as I'm wondering That's kind of broken Like the the v2 the v1 sdk implementation is incompatible with the spec That's good. So I can take a look at that. Uh Can someone I guess links to the current when you guys want headers and stuff or somewhere when you guys I think I wrote an issue for it For it All right, yeah, I'll take a look. Um, I was just on the Rapper issue, uh, so I didn't know though Curtis did you mean to me yourself? Oh, um, yeah, I I'm echoing. So that's why it was actually grant I think we might have been coming from grants. We'll try again. He's muted now. Okay Um, so, yeah, I haven't I hadn't gotten a chance to look at all the issues I was currently just looking at the pythonic one because that was one of the older things And that seemed like a good place for me to start Uh, but I can definitely um look at, you know, What's broken with the support? Which issue was that exactly? Was that using extensions with dictas? Yeah, right 32 That's the only thing that prevents this out of the box from working at the moment So, yeah, I will I think I might have So Curtis, are you are you planning on taking a very active role in this SDK? Yeah, um, I planned on more like right now on my branch It has an out of the box. You can just create a flask server and use events to emit and stuff um, so I had gotten that at least working to Um, decent amount so I can work on this like over the summer while I'm here Okay, because it sounds to me like we we really need somebody to own this puppy going forward because I don't think we have anybody else very active and I'd love it if you if you would like to you know volunteer for that and then you know, we can make you a maintainer and all the other Good stuff because what do we? Say it again. All right. Are you an intern, Curtis? Yeah, I'm an intern at the moment. Oh cool. Where are you interning? Um, I'm in new york and I was on the cloud run team So, yeah, neat. Awesome. So you're a googler then? Yeah. Well, newbler Newbler, sorry Okay Uh, but yeah, I'll definitely I'll post um, some links like this to my forks and I'll look at the other issues Uh, soon one at a time Okay, so Yeah, so from from a process question It doesn't sound like anybody can identify anybody who's actually really active on this sdk Is that correct? Yeah So to my knowledge, um grant had told me that my point of contact would like to end up being um, I think his name's dustin ingram So, uh, I think we have a meeting with him on friday So I was going to use that to capitalize and get more knowledge on you know, things I don't know that I don't know Okay, cool The reason I'm asking is more from a process related question because obviously you it'd be great Obviously, you open up prs review these issues and do all the great work. But um, if either dustin's not there or Dennis isn't going to be there to review your prs. Then That's a problem, right? And so we so we need to think about making you a maintainer and I don't think that's A problem because we we will make people maintainers if there's no one else in the group to to say yes or no Right because we need somebody Um, but let's make sure that we're not going to be stepping on someone else's toes if for example dustin is actually very active And we just don't realize it Yeah, that's so as grant said before the last committee was in like april 27th. Um So it's a little inactive, but definitely like, you know, it would be nice of another person to get PR Is done in a timely fashion. Yes Let me know how the conversation with dustin goes and see whether he's planning on actually being active or not That'd be helpful All right, cool Yeah, um, so just for context. Um, so I'm I'm going to be working with Going recently Yeah, so our plan is uh, if it's okay to improve the python sdk over the summer and We'll be Curseful He's sending the prs and um anybody that's really interested Can be involved too, but uh It'll be any greatest Dustin since he's Um Thank you. Cool. Sounds great. Thank you guys All right, uh anything else for the agenda today Could be a very short call One once All right We are done then. Thank you everybody and we'll talk again next week Have a good rest of your week. Thank you Thank you. Bye. Bye. Thank you. Bye. Bye