I am good morning, Doug. Good morning, mr. Mitchell. Good morning. Good morning. Looks to us Lance I'm here. Hello. Are I Hello, hello Francisco Hello No, Tommy. Hey, Tim or Hey, I don't think I'm spelling there right, but I'll fix it later. Eric. Hey Good morning. Good morning Christian Hey, Doug. Hey, hey Hines Good day, sir. Good morning Thomas I'm here. Yeah. No, I'll get it. I'll get it Mike. Oh, Mike. That's a mic. Yep. Hey, Chris. Oh Good. Hey, Mike Hey, Jim morning Hey, hey, Manuel. Are you there? Hi? Yeah. Hello and Brian. Are you there Brian young? Yeah, sorry muted, but here. Thank you. Is this your first time on the call? It is my first time in the call. Cool. Give me a favor and Let me paste a link to the doc if you can just put your company name in there On the list of attendees if you want to be associated with a company that is Okay, perfect. I'll just do for a soft thing All right, Vinay. Are you there? Hi Doug. Yes, I am. Hey. All right. One more minute then I'll get started Doug It's all like Would you say I have to put it because I Don't know if maybe we have already done it. Yeah, I think I already have you in there We're like, okay. All right, cool. I think you're good, but we'll check. I have you from Pivotal. Is that right? Yeah, we're Pivotal. Thank you. Okay. Yeah, I wasn't sure what to do with you guys. So I just picked one Well, I'm still Pivotal because France is not yet being acquired Okay All right Let's see. We are three after. Why don't we go ahead and get started make sure I'm missing anybody. Oh Kent Hey, can't see you there. I don't have a microphone yet. I'll catch up. I'm later. All right. Let's go ahead No eyes worth mentioning about community time anything from the community people like to bring up. All right, not hearing any So I think I mentioned this last time the TOC would really like to see us become a SIG not just a working group under SIG app delivery We had an initial meeting with them Monday or Tuesday this week. I can't remember which one And they gave some suggestions in terms of how to maybe tweak the charter a little so I'm gonna take out another pass at that they they still really seem eager for us to be our own little SIG because Serverless is such a hot topic and they didn't want to they don't want SIG app to their weakness. They get too big either So I'll do my best to try to find the right wording and we'll see how that plays out Okay SDK so just a reminder we will have oh is there a question? Yes, sorry I couldn't find my raise hand. Sorry about that Can you I tried to follow some of the email threads on this differentiation between Runtime and SIG runtime and SIG apps and could you just maybe talk about what the general Consensus is going forward in terms of how the differentiation is is being facilitated like for cloud events Is that still that I'm assuming it comes it would come under the SIG apps, is that right and not the runtime and You're asking a really hard question this which is why we're struggling with this So as best as I personally can explain it and someone else can please chime in as best as I can explain it SIG runtime is more for things like Kubernetes where it's base level infrastructural thing Low-low level type stuff. Okay SIG app delivery is meant to be I think a Simpler user experience which is why you're gonna see things like Helm show up there if cloud found a word to appear under scene CF one day I'm not saying it should I'm just saying as an example cloud founding might appear under there that kind of stuff So it's meant to be a simple for a simplified developer experience. It'd be app delivery It's all about delivering your application in the easiest way possible now that the challenge then comes in to Well, how do you distinguish app delivery from serverless because well serverless you can focus on it? Oh, well, it's about you know functions of the service. It's about scale to zero. It's about pay as you go and those are all true as we've seen the line between Serverless functions of service containers of service platform service is actually getting very very blurred and a lot of the stuff That we talk about in the serverless world nowadays can very easily be applied to say platform as a service, right? because if you look at say Something like Knative versus cloud foundry if you ignore some things like the scale to zero stuff that Knative brings to it They're actually very very similar, right? And so the line between those two worlds of app delivery and serverless is very very blurred and that's why we're struggling with this right we can't come up with a crisp definition of What a serverless sig is versus app delivery sig, but we're gonna try and To be honest the wording we may have in there may end up being something along the lines of We're gonna try to make an attempt to turn to to split the definitions, but in all reality We're probably gonna have to take each project that comes to the CNCF on a case-by-case basis to see whether it's best fit for serverless Versus app delivery and there may not be a good rhyme or reason other than each one is a special snowflake that needs to have its own decision made That's the best I could do Right. No, no, that's very helpful. And also maybe if I could just taking on that community time just ask another question. I know we call this working group or the sig working group as the The serverless working group, but we have most of the focus has been on, you know, for example, the cloud. I mean, I think the last two months we focused on cloud events. So how is that distinction handled? Is there a separate sig for the serverless or This is and or do you just see this as a critical piece of the The the massaging ecosystem that is fundamental to serverless So again, this is just my opinion. But the way I've kind of thought of it is Until we become a full-fledged sig, I've been kind of ignoring the question Because once we become a full-fledged sig, I think there's going to be a fair amount of more A bureaucracy we need to deal with for lack of a better phrase and at that point we probably will have to spin up a Dedicated serverless sig phone call that's separate from cloud events For the most part we've been kind of lucky in that Most of the work that's gone on the serverless working group has all been Focused on one particular task, right? We don't have multiple things going on at the same time However, if you look at the workflow stuff that did spin off into a separate Not working group, but subgroup under serverless and they even have their own phone calls and their own slack channel stuff like that So we can fork as necessary. It's just we've been lucky that for the most part everybody who Wanted to focus on the serverless side of things has said, okay Let's all focus on cloud events and that's why we only had one phone call But we will spin up other phone calls as necessary. Hopefully that answers your question Yes, it does. Thank you. Cool Okay, any other questions or saying I just want to chime in there to give alternative point of view All right. Thank you. Everybody. Um, okay as I was saying SDK call We will have one every week going forward starting with this week. We did have one last week I for life me can I remember what we talked about? Um Did somebody who's on that call remember? Yeah, we talked about the uh the type script. Oh, yeah Yeah, that that that took up the whole call didn't it basically Yep Okay, and we are going to continue that discussion today if we have time on this call we'll we'll jump into it if um If we don't have time on this call, then we'll just do it again on the SDK call, but um, there is a whole discussion about whether We want to keep the type script as a separate SDK from JavaScript now on last week's call We agreed to create the type script SDK repo as a temporary measure Um until we have a formal decision just so we don't hold up those guys from the other work done Um, but if for some reason we decide we don't want it and we want to merge the two into one repo We can kill off that repo, but that's the discussion for later in the call Okay, and just reminder we will have the SDK call immediately after this one even if this call ends early We'll start it up All right, uh teamwork. Is there something you want to mention status wise from the workflow subgroup? Uh, yeah, sure. We had our meeting with the argoteam and I think manual if you can just give us an update on that Because you can allow that Yeah, so we reached out To argoslack and alex Collins one of the founders And uh, we had a meeting on monday with 17 people attending. Um, so we have them from into it was alex Collins then at lee And uh mukulika kappas this we are from into it that were most active in the discussion And they seemed pretty interested in the idea to have a common standard language That is also not bound to the platform as uh in kubernetes Custom resource descriptors So um, they are going to join us from our next community call And maybe also on our next primary discussion starting again on monday To drive forward a common specification and thanks to theomia's work. Um, it seems that what our goal does in our goal workflows and our grievance is pretty much aligned with the capabilities of the current dot one release of serverless workflow language Um, and we're pretty positive on finding some agreement with them That'd be cool Excellent any questions If i may just like we're doing the same now with the brigade project. So we have started working on examples as well Um, but i do want to ask you Doug like with the serverless sig like we're currently going through the sandbox project proposal with the sig app delivery Is that have any implications or not? With that You think it would um But i wouldn't worry about it until we figure out what we're doing with the serverless sig Okay Yeah Okay, any other questions for the workflow team? All right, moving forward then just a reminder. Um While we I do take attendance and we track these things. We've had a lot of new people join the group recently I just want to make sure everybody understands the reason we do this We don't often take formal votes. We try our very very best to get consensus for Most decisions, however Obviously, there will be times that we can't necessarily all agree and we have to take a formal vote And the way voting works in this group is not through prs and stuff like that because we don't have a You know a daily stream of prs like a normal quote open service project would Rather we do it based upon attendance and typically also it's associated per company So what ends up happening is? I do take attendance and that's why I ask for people to associate themselves with the company And each company has a primary and alternate as long as one of those two people show up for the last Uh three out of four phone calls Then that company gets voting rights Okay, so that's why it is kind of important for one for me to make sure that for you to make sure that I hear you on the call or Say something in the zoom Chat and I'll mark your attendance there. That's what the little asterisks means up here.  So for example, let me pick on red hat for a minute here for a long time Both of the red hats primary and alternate folks Did not attend the call Where is it red hat? So I I reached out to Lance and said you may want to change that so he became the primary this week I have no qualms about changing it around as necessary and he didn't lose You know his his attendance like that. So right now they're agreeing so they can vote um The only constraint that we have in terms of switching these things around is If you end up asking to have the primary and or alternate change on a weekly basis because on every week a different person shows up That's not within the spirit of things, right? We're trying to get people to show that the same person to show up on a fairly regular basis so that they have A continuity in terms of understanding what we're doing right because we don't want people who show up Just to get voting rights because first of all as I said, we don't vote very often So voting rights really doesn't matter that much and it's very rare that we actually need it So As I said, you can change around as necessary It's just on a weekly basis. You're gonna get some eyebrows raised of that. It's thinking you're playing games And that's what we're trying to avoid Okay, that quick question Yes, we took questions on this on the subject I actually see my name and no zero no two no three nothing there so Uh And we've been in the last three four calls three calls Yeah, so reach out to me because mark fishers your primary for piva.  Um, but um, Anyway, that's not the biggest my other question was probably more important. Um Sometimes there will be people like let's say subject matter expert Who may be one off to join the call to discuss a particular pr or something and or and that may get into Into a bind Uh, but that person effectively doesn't have any voting rights because he just Got in there for the first time. How does I mean, maybe you just never encountered that situation before No, so we do it No, and so obviously this is an open call anybody is free to join. Um, right, right. That's my point. Yeah Yeah, if they just show up once that's fine. Actually if you look like you look down here, right We have a whole bunch of people who actually show up once and I you know way over here a little yeses form I keep track of them all in case they show back up again. Um, and so that's that's perfectly fine It's just if they don't show up again, or they're not associated with a company that shows up on a basis They won't have voting rights, but it doesn't matter, right? They don't show up often enough that they really care I will point out though for some people like take Vlad for a pick on him He is not associated with a company. He does he does his own stuff So it is possible for people who don't want to be associated with a company either because they don't have a company Or because they're doing this on the rolling. They're not officially part of the company They can show up as just self and that's fine as well and they will give voting rights. You can see we have four people right here Okay, okay It's not a big deal. I don't worry too much about this stuff. As I said, we don't know that I just Yeah, no, I wasn't focusing on you. It's just in general. I know some people get a little nervous about this stuff But like I said, it doesn't really matter. We've had I think less than 10 votes total for the entire lifespan of Out events. So it's very very rare that we actually take votes, which is I think a good thing Okay, but I did want to mention it for people who don't understand what the heck we're doing And why I care about so much about hearing about people from the attendance list All right, any questions on that? all right now Let's get into some real work um so We talked about this last week and Fabio Indicated that actually let me show you the comments so you guys can read it yourself He indicated that Well, this is a breaking change in terms of from a code generation side of things. It's not a breaking change for what's on the wire And he I'm interpreting his comment here as saying that means we don't necessarily need to create a 2.0 of the avro spec so this is more of a Maybe an sdk impact kind of a thing or a coding impact kind of a thing um If you if they're using the schema it's my interpretation of it I want to hear from other people in terms of what they think about that Do they think that's a satisfactory answer for us not to have to worry about this being a 2.0? Or is he playing fast and loose with terminology here? I'm actually reading so yeah, okay, and I will I will pick on people if they don't want to speak up Because I know we have some quote standards type people who Think about these things often and you know who you are This does not require a major version of Clemens I want to pick on you It's your price for not picking on the call last week ah um if I think this was the this this was to disambiguate the or to make clear that this is just the avro Encoded way of doing a cloud event and it is not the cloud event as it should be a memory, right? Um So he's the these sets of changes he's making yeah Right um he claims this does not affect what appears on the wire Uh, I believe that's true Because the point of the schema is to avoid it is not to have the um the names in the on the wire So this sounds like it's more like impacting stk or just customer coding stuff up type things, right? Yes Okay, so so it needs it needs a version. It's it's a breaking change Um, but it's not it doesn't have wire impact So either schema should Um, well when I'm willing to trust professionals Um, so so I'm not I'm not gonna I'm not gonna question I'm not gonna question the statement if he if he says so Because I mean the easy the easy way to prove this is to basically Surrealize out in one with the one schema and then serialize back in with the with the other schema and see where that breaks but I guess that that's um um So I'm assuming that it has happened I don't know ha The way I read Fabio's comment because it was a little confusing Where he says the PR does not change and he says these breaks But the way I read it is The usage itself for somebody who expects something May break or will break but on the wire The context of this cloud event will stay the same I guess that's yes, so I I don't think it's breaking from the sense that it's from the if if it doesn't have wire impact, which I believe Yeah, it's not that I say I know it's just that I I believe the theory. Let's put it this way um Then then right It nothing breaks until you take on this until you take on the schema, right? It's up to you So those two schemas the old one and the new one are compatible on the wire Which means you can now go and take this new schema, which is which can also be you know 1.0 a um and uh and that will that will work what what they will do is it will for the future and for Everybody who takes on that schema clarified that whatever you co-generate Is just the the the avarice serialization of the cloud event and it's not the the actual cloud event object that you would get if you are taking the stk So this is it's effectively a clarification. So it's fixing a bug and so therefore um, it's It's not a breaking change in that way Yeah, I like the fact that you said it's a more of a bug fix Yeah, even though it feels like we're being a little bit generous with that. Um, I I see because I stand up to excuse You know, we'll we'll do that if whatever if there is a breaking change we say well, actually it was a bug when you have to It's it's a it's a breaking change. It's it's a breaking change in the sense that Yeah, if you've previously relied on the the avarice serializer spitting out a class with That or an object with that particular name, then yes That is a breaking change. So that's why we need to have a new version number, but it's not a 2.0 I think that's the argument here. Okay Is there anybody on the call that would look at this situation and say Or we're kidding ourselves. This really needs to be a 2.0 Okay, not here. I look at it even more as like a sort of a standard schema evolution case. I mean It's constantly used in messaging eventing apps where schema changes and we have a dynamic way of retrieving schema and applying a particular specific schema On the object that may have went through the schema evolution change. So I mean, there may be like a different way of even approaching it, but Maybe outside of scope of this discussion But I mean, I don't see it as a your classic breaking change Yeah, this from my opinion I see it more of a developer you know, there are breaking changes, but if it's a It's not like something in production of all of a sudden just crashed I mean, it's something that will be discovered in my opinion early in the development phase and months addressed No longer an issue Jam your hands up Yeah, I think I was going to say the same thing actually for me a breaking change. I think it's really Yeah, a change to the wire. Yeah If you remember we changed the jason schema right up You know, I know we hadn't released 1.0 at that point, but we changed the jason schema It didn't change the format on the wire, but it did change the way we represented It from a schema gen perspective. So that would have changed code um, so I would I would tend to sort of Let this one through on the assumption that the wire format isn't actually changing And I don't think I can comment on that Okay, anybody else have any alternate point of view on that Okay, in that case, is there any objection then to approving this pr? All right. Thank you everybody. Next one. Thank you Um, hold on a minute. There we go Okay next So this pr Unfortunately, I meant to get it done Tuesday night, but I don't think I did So I ended up doing it yesterday. So it's too soon to merge However, I did want to have a discussion about it in particular mike. You are still on the call, right? Okay, good so Hold on a minute. Let me hide comments first so basically What I tried to do here was I thought that the I think Okay, I always get the the p words mixed out. There's provider and producer I think it was very confusing having both words in the spec and I tried to actually eliminate that And what I then also tried to do was to talk about and I stole a class's idea of using a term called source class which is Sort of like source, but it's not as specific, right? So in the in the cloud event source uh world or usage The source actually gets down to maybe something like the actual bucket name if you have an object store Source class is something that's a little bit more abstract in the sense that it's meant to represent The object store itself not necessarily the actual instance of the thing inside the object store that produced the event And that's why we I use the word source in there, but then we call that a class to imply It's it's related to it, but not quite the same thing Um, however, it is meant to be a unique identifier for the thing. So if you actually look an example down here You see source classes example.com Um, but the actual event itself might be example.com slash bucket slash food or something like that, right? And what I wanted to then do was to show When once you did that if you took all the other properties that I think might defined And just showed them in a very pseudo YAML-ish type format. It's not 100 yaml because I you know the asterisks and question marks show whether it's it's cardinality and stuff But I thought this gave a nice Very quick overview in terms of how things would actually appear if for example, this word appear in yaml on the wire Um, ultimately you probably would want to convert this to something more like jason of jason is the preferred format We want to support, but I wanted to take a step forward in terms of Producing something that was a little more concrete Than just a list of attributes that mic had And show them in a format so people can understand. What would the data model at least conceptually look like?  I think it implies Abstraction like I immediately go to like the idea of a class in a programming language, right? it's um Anyway, I don't I put a comment on the pr. I suggested source system But I like in or in reality this would indicate like a specific product That somebody is subscribing to events from um, I was literally gonna Complain with the same class as a developer. I was like, uh, what and what is example.com? That's really not a class So let me uh, I as a latecomer to the overall discussion. Let me ask a stupid question Example.com or whatever that down below that you yeah example.com Could it just be any kind of I mean because your documentation states uniquely called a unique unique name So it could be any kind of unique name as long as it's unique it is Where it should be of certain format like, you know, like a domain name or whatever I think I think so a couple things To mike's comments about the name. Honestly, I I'm okay with source system I think that that actually probably is a better phrase for it. Um, I don't I'm not married to the name I just was really bothered by the two words to start with p provider and producer being so close together That was my biggest concern. Yeah. Yeah Let me say to the other one the the second one is We need to go through and make sure for all of the properties What their actual types are what the scope is now my interpretation of this particular thing is that I believe cloud events source is a uri um, okay And so I would assume this would be a uri as well and in terms of uniqueness I think it just has to be unique within the scope of this particular Discovery endpoint that's that's my that's my take on it So then Again, maybe a stupid question. Why? Because I see that people don't like source systems source groups or source group is one suggestion. Uh, but source, uh uri I mean go for a simple one Well, so the reason I I it's funny. I think in I'm just throwing it out there. See if it sticks. No, it's all good It's just I think at one point in the in the chat I actually didn't mention using word source there But the problem was camera who it was whether it was mike or class mentioned That may be confusing for people because they may look at and say, oh, what's the cloud event source? Well, it's not right and I don't want that confusion either. So, but I think it's important to think about where this would be displayed so like I might my Thought your thought process here was that whatever whatever we call this string That it might show up in a ui For somebody to like drill down to oh, I can pick events from my storage provider from my database provider from my Audit log provider like they're going to be identifying it by the name that they know that system by Yeah Source group the suggestion based on what I'm hearing Yeah, I mean we can we can rattle on the name itself, but um I think we should let scott name it I know how much he likes naming things. Yes The other thing that I did change and mike I wanted to make sure you you were aware of this was In your in the current form of the spec You actually have what I call description as sort of the main key as a the human readable string And I flipped it so that the machine readable thing Um is the uri that way it's guaranteed to be the same Hopefully that's the thing you can search on I didn't like using a human readable string as the search string because That could change over time right companies get bought out or there's a fat fingered the name at one point They need to rename it right that kind of stuff Um, so I want to make sure that you notice that and you didn't have any concern with that Because later on when I do talk about samples I talk about using the source class as the search string not Description thing even though you could support searching on description. I thought that wasn't the primary use case I think you probably want to support searching over multiple fields, but yeah, yeah, okay yes Okay, um I thought I saw a hand go up there for a second. Oh thomas Yeah, I was also looking for the unmute I'm doing it with the spacebar right now. Um Behind source class you write unique identifier for producer, right? So I was thinking of why don't you name it either producer or producer id Juicers already taking That's what started this issue, right? The producer the producer is the one who is putting the event on the wire, but the source may be something else Yeah, I I probably should not use the word producer here. All right. I honestly, I don't care about the exact wording I just did not want to have two words that look so similar. I probably should have said unique identifier for the entity Making the event or I don't know something like that, right? Yeah. Yeah. Yeah I think that's exactly where I struggled as well with the producer and the provider and the source and uh, yeah I think that's exactly where I Added that issue a couple weeks ago, but I didn't have time to to work on it, right? Yeah, and to be honest I could throw out a crazy suggestion I think the I think the problem this problem arises because of the way source is defined in the cloud event spec And I personally think it's defined incorrectly Oh, Mike, you're going down someplace. You don't want to go. I know I wasn't around for when those discussions were had but uh I think the way that source is used is weird Okay, bring it Bring yourself, Mike I mean, I think when I think of source I think of the system like oh, this is coming from google cloud storage or this is coming from Uh, mongo db And instead we've made that to be something more like what subject should be like So you have this weird combination of source and subject to actually find out Um a little bit of the thing that that uh, you have And the origin system is mostly described by the event type but event types are not required to be unique by origin system It it's there are scenarios where that's not so easy for instance, if you have a industrial Machine That industrial machine may have something that's happening kind of deep in the bowels of that box That you want to go and report out But the the the part that actually does the reporting that is the producer. That's the one who's formulating the cloud event Is something completely different. So that's that's far away. So that producer may actually be responsible for 500 different things that exists in in In that machine and they're not all the same thing it might be reporting on behalf of a sensor It might be reporting on behalf of a drive. It might be reporting on behalf of a whole universe of things So there is a producer and that's the one who's formulating the cloud event And then there's a source and that is effectively what that event is about and those things are clearly distinct Right, but the producer doesn't appear anywhere In the payload That's correct. I'll now make sure the thing that that can be hard to talk about Well, I totally get I totally get wise the use of source in its current form The name has always bothered me But yeah, but it's not so so I understand that but we have we have things that that are affecting producers and that is for instance Authenticating towards a party where that event gets being sent is being sent. That's something that the producer has to do and not the source And then there's other aspects like how do you and this is something that this that this here describes where another role is Touched and that is the subscription manager, which actually is the point where we are Distributing those events from so that thing is neither the producer nor the source Because that might be the middleware Which is which is helping the producer Distribute its events It's an interesting discussion because we also interpreted source As really the machine which actually sends out the event and not the the sensor which Triggers the occurrence So we interpreted. I think exactly the other way around Yeah, and so so we meant we meant source to mean literally it is the the unique identifier of the thing or the context Where the event comes from so that might actually so source might might be a very rich description of Detailed description of you know a sensor that sits inside of a of an industrial machine Well, the producer is the thing you configure to go and send those things out to map this concretely into something that is In the industrial realm In opc way where we're introducing opc ways is an industrial standard We're introducing cloud events there. I wrote the the the binding spec in for opc way for cloud events That's currently floating around as a proposal over there and There the producer is really the opc UA publisher which is collecting events from within the opc UA Adder space where those are getting getting raised so that the the source your eye is constructed based on the identifier That is exists in that opc way adder space Well, the producer itself is identifying itself with its identity Identity towards the the all the network actors. So that's why those things are really need to be different so I don't want to rattle too much on this. I think I think everybody's agreed source class is not the right phrase for it and I'm okay with that I don't um, I will I will and I'll remove the word producer okay, um I'm okay with I think someone said source system. I kind of like source system just because the word system in there implies to me It's like the the the bigger entity but to be honest This a lot of these field names may actually change As we go through the cycle, right? And so right now my bigger concern is Whether the overall direction of this pr Is heading in the right direction or there's something fundamentally wrong with it because at this point in time in our life cycle We have to get to the we have to sort of assume That each step is just better than what we have right now and it may not be perfect But it's a step in the right direction is what the biggest criteria is Okay, well, we're strive for perfection as we closer to 1.0 so Mike in particular, I did want to pick on you aside from the naming aspect Does the direction I've taken here seems sort of okay with you so far mic? Uh, I mean, I'll be I'm I'm trying to read through the pr at the same time. Okay, and don't don't don't don't worry Like I said, this is too soon for us to approve today But I did want to bring it up to people's attention and I'll obviously make these changes to it Provide feedback in the pr itself as we go forward and just don't get too hung up on naming if you have a good suggestion I'm all ears But don't get hung up on thinking that once this pr is accepted or if it's accepted That everything set in stone As gem mentioned, we changed lots of stuff right for 1.0 in relative to Jason's schema So we have no qualms about that. We're just trying to make forward progress Okay, and I did take a take a quick stab at trying to show what some sample queries might look like Um Not set in stone just my quick rough idea because I wanted to show How I didn't think the query format would necessarily have to be very complicated the questions I had for the group and I don't necessarily have to have an answer now But the questions I had were things like When you specify two different attribute names, is it an or or an and I was assuming that different Yeah, go ahead Why queries instead of the rest paths like we had before? I have no idea I forgot about that. I just this is just the one that jumped my head as I was typing up the pr Yeah, so I'll go back and take a look if you yeah, and that first, uh, you just scrolled. Oh, sorry Oh right around like 162 Yeah, so before you would have been able to say like, you know hostname slash Source class slash example dot com So just buy buy get buy get rest pass give me all of the uh entire the data model for that provider So in that model, I understand how you could do that for something like source class When you get down to something like protocols and types where there's more than one How did you see that playing out if I want to say I want uh the the source The source system that has Two two event types and I want it to be an and or an or and how do you do that kind of stuff with the path thing? I mean you can have queries on top of on top of paths for sure But the you know that the whole the whole the whole point of rest, right is that you have canonical paths for access to objects Yeah, and I think that that I guess I'd like to see how it looks because if you're searching on source Class that makes sense to me because that is the hopefully the next object in the in the path But if you wanted to instead search on description, which you said you did want to be able to support Yep, how would you see that happening? Well, so the other So the two common cases are searching on on source class and searching on type, right? So in the in the original pr There were rest paths for both source class and type so you could go in and say give me you know give me um Get at slash type slash com dot example dot storage dot upload, right? And it would give you all of the source classes that match that um But there's no like there's no reason that you can't have a rest path with a a query filter after it Or or for that matter, you know get source clash question mark query string, right Which is also I think in the original as well It's for a listing. Okay. I'll take a I'll take another look at that Like I said, I just completely forgot about that as I was writing this up. Yeah, no worries Okay Any other questions on the direction I was hitting here? Obviously, it's too new for deep comments But anything that's jumping out of people and they answer questions now Okay, and hey, please take a look at it. I'm open to any suggestions um Let's just not rattle too much on naming It's my only request Let's see in terms of other prs francesco, did you want to talk about this one or not I didn't any progress at all. I didn't have time for this. Okay. That's fine In that case before we jump into the typescript discussion. Are there any other topics related to any of the specs we have? Oh, Clemens, did you want to talk about The schema stuff or do you want to wait until your proposal you sent that you're going to send that before Wednesday next week? I'll just mention it because Not everybody may have seen the email. So I'm So thank you very much for Approving forming the working group. We'll see how big that is I will turn that issue the text in the issue into a spec and Also provide a Swagger document along with it that describes What the shape of that is I wanted to do that for this week, but There's a lot going on and so I couldn't I'm also asking for some help from our engineering team And we'll hopefully have that then for review next next week Germany has a holiday on thursday at least where I live. So I'm not going to be on the call next week But I'll have that for review For the schema registry If since schema registries are not necessarily novel If any of you have an existing implementation of the schema registry It would be a good idea to raise your hands And potentially also point to any existing documentation you may have A condition for that is obviously that the schema registry is one that you own and That is not unencumbered not encumbered by licenses that are not open So that we can't take that in because ultimately that's going to be owned by the cncf and So that would be the only only condition for that I guess but Whatever we're going to propose here from from the microsoft side is not necessarily the last word I think And we're totally open to You know, whatever solution comes out of this So and then I'm obviously also interested in folks who are interested in driving that forward with us In this group and I think we need to go and decide whether we're going to discuss that on In this group here in that forum, whether we're going to make a sub working group As we did that for the discovery and subscription documents to at least boot it so if It would be great if you could think about whether you are interested in participating in that effort And I said I'll I'll have a proposal out mid next week That formalizes effectively what the issue is but the if you look at the issue then The shape of this will not deviate from from what we propose there Any questions for clements? All right. Thank you clements looking forward to that All right with that, um, I have a very strong suspicion that we will probably not come to any any kind of formal vote on whether We should keep the stk repo. I'm sorry the type script stk repo around or not I have a feeling this is going to be a long discussion So if you are not interested in the stk side of the group, feel free to leave We're not going to take any formal votes if we end up And a miracle happens we come to a decision. We'll just defer the vote until next week So you won't miss it. So feel free to drop off However, if your name does not have an asterisk next to it in the attendee list Just put a comment in the zoom chat. So I know you're here and I'll put a star there Okay, actually hold on. Let me just do what I normally do hold on Um kent. Are you there? Yeah, I'm here. Okay. Dustin. Are you there? Howdy. I'm here. Hello. Remy. Yep. Hi. All right. Nick. Are you there? Nick. Okay. I got mark here. Sam. Are you there? Sam. Okay. What about Sergei? Yep. Okay. And grant Over here. Okay. Did I miss anybody? I'm sorry. Who's that? Matias. Okay. Okay. Okay. Oh, hey, Klaus. How did I miss you? I even talked about you. Okay. Anybody else? Okay. Remy, you might be new to the group. Do me a favor. Paste your company name in the zoom chat if you want to be associated with the company. And with that TypeScript, who would like to lead off the discussion here? That quick question before we jump into that if I may. Yes, sir. Um, is this TypeScript for the next hour is the only thing we're going to be discussing? Or there is a because the document has no agenda. That's why it was. Um, yeah, I apologize. I was going to check that if there's nothing on the agenda, then this will probably be the only topic. Unless someone in the next hour can come up with one because a lot of times we do play by ear. I mean, I have an agenda that I want to discuss, but so that's why I was waiting for April. I mean, May 14 thing to be created. Oh, sorry. Sorry about that. Tell you what, while we're talking about the TypeScript thing, I will go and add the section header and then you can add it to there. Okay.  Oh, yeah, I wanted to ask, actually my zoom client crashed, but wanted to a quick ask an SDK question. Would that be possible before you go into the TypeScript? Sure. I tried out the C sharp SDK and quickly need to switch my screen since my client crashed. It's difficult to get out. Oh, here we go. And my question is I used content mode binary and then I also tried content mode structured. And in both cases, all the HTTP header fields were filled in. And I wasn't sure whether this is intentionally or this is a rather an issue. So that's that I wrote that. That is intentional. So we kept it optional in the in the specification, which means that even though you send structured, if you're sending structured mode data, it's permitted to also send the attributes in the transport headers. And I thought it's the other way around, isn't it? Because in the structured mode, you use content type cloud events plus JSON. Yes. Whereas in the binary, you only use application slash JSON. If you're sending, if you're sending JSON, that's correct. Yes. So, so, but the headers, so which headers are you confused about? Yeah, I was just confused because I watched a video from Doc, actually, where he explained HTTP binary, which show the header fields. And then on the structured slide, there were no header fields. So, so the space, what the specification says is that if you're sending structured mode, and you're sending it over HTTP, then it's still permitted for the for the headers to appear as if you were sending structured mode. Okay. And so I'm choosing to do that in the C sharp SDK. Okay. Because there may be an intermediary like a proxy, who's actually interested in some of that information to do whatever it likes. And so independent of what you choose as the encoding for the end to end relationship, that you're still enabling the proxy to go and take a look at those headers. That's, that's why I'm, that's why I'm doing this arguably. I could, I could go and add a switch there. Fine. It's fine. Just wanted to know whether this was intentionally. That's no accident. That was, that was fully intentional. So any intermediary should actually check for the header fields, no matter what the content type is, right? No, it doesn't have to, but because the content type per se, the content type per se is a clear indicator of what you're looking at. Okay. But nevertheless, they can look for the HTTP header fields. Correct. Yes. So they could, they could, for instance, look at C, C e dash subject. Yeah. Or C e dash source and make some decision based on that. Okay. Thank you very much. That's the answer to the question. So look to the main topic on the agenda, TypeScript SDK. Lance, Grant, when you guys want to kick off to bring everybody up to speed on what's going on and what the question is. Yeah, sure. Can everyone hear me? Okay. Yeah. So there is an outstanding issue and the cloud events SDK for JavaScript. And that issue is around TypeScript support. TypeScript is a superset of JavaScript used by many companies that allows you to have static types during developing time to ensure that your code is more type-proof and safe. And it provides a great developer choice. Right now there's no support for TypeScript in the JavaScript SDK. There has been a lot of discussion in the GitHub issue around it. And there have been proposals around annotating types. But there's been some, I want to say, resistance on adding TypeScript. The actual change would be changing the file extension of the files from .js to .ts. And then adding a watch or compilation step. Given that there's a lot of interest in TypeScript and personally it affects my work and a lot of other work. And there's not been any progress. One of the recent decisions, temporary decisions was to create a separate repo called SDK TypeScript that would in fact fully adopt TypeScript. And it would still be a module that's published to NPM. But it would allow for some of the features that, well, it would just support TypeScript. That's currently the state. I created a pull request recently to initialize the TypeScript repo. And that's what you see there. And yeah, I think one of the biggest advantages is that you'll get this great ID auto completion. And you'll get like linting errors. And you'll get a lot of things that you don't, that you really can't get without providing types. I think this will be really useful for developers personally that I work with that are consuming cloud events. Okay, thank you. So just, I'll pick on Lance in a sec. But just from my point of view, and I've made it perfectly clear in every comment I make, I don't next to nothing about this stuff. And I want to, however, I do think it's important that we don't necessarily get a discussion about whether TypeScript versus JavaScript is one better than the other, anything like that. To me, the overall question is, can we do both in one repo or not? Because I've, from my outsider's point of view, I feel like I'm hearing slightly different versions of what's possible. On one hand, I hear somebody say, yes, it's possible to do it. We just need to have compromise. Other times I hear, nope, it would be better for the end users if they were separate. I don't know what the answer is, but I think that is the ultimate question we're trying to get here is, does it make sense to do it in one repo versus two, not whether one is better than the other? So now let me pick on Lance. So I know you have an opinion on this entire discussion. Of course I have an opinion. Yeah, I personally would not, I don't think it's a good idea to have a separate repo. I think if that's where we land, that's where we land, but I agree it splits the community. This conversation has been going on for about two and a half, three weeks now. And I feel like I've compromised a lot and put together a PR yesterday that introduces TypeScript in a way where it generates type definitions and does the sort of type checking that Grant, you were just talking about, like your little screenshot there in the, yeah, that one, that works with generated type definitions and stuff like that. And personally I feel like this is a nice compromise on a path towards potentially switching over completely to TypeScript. The way I look at TypeScript is there's sort of benefits in two different communities. You've got your people who are maintaining the repository and you have your end users. And most of this discussion has revolved around what is the benefit for the end users. And as far as I can see doing type definitions and good quality Javadocs, which can all be enforced through Linting, is a nice compromise on a potential path towards what am I trying to say? No, the end users. Yeah. So for end users, I think it gets us there or at least it gets us like 95% there. I don't know what that other 5% would be. I haven't been able to see it, but it seems to me like it gets us there. For the developer side of the, or the maintainer side of the community, you know, there's a much, much larger pool of JavaScript developers who would potentially be able to contribute to this repository if it were, if it maintained a pure JS implementation with type definitions and good quality JS docs. The question has been, well, okay, if you go that far, why don't we just change the files to .ts and have the transpilation step every time? I guess my question is if we're just sticking with pure JavaScript, then why have that intermediate transpilation step? Because we're going from a .ts file with pure JavaScript to a .js file with pure JavaScript, and it doesn't seem to provide any benefit that I'm aware of. Maybe it does. I just don't know, you know, I'm not a TypeScript developer, and that's part of the reason why I would like to find a compromise that doesn't require us to completely change the repository to TypeScript but solves the problem for end users. Okay, remain your hands up. Yeah, I think like the sum up from Lance was pretty good. I think for the end user, the PR he did last yesterday, basically kind of solved it from the visibility from the end user. I really think for an end user point of view, it's really bad if we end up having a split repo because that means you will have two packages on NPM, and it's going to be really hard to track what is the official, even if it's two official packages, it's kind of really weird to see that, I think in the world. And then on the comments, I would like in fact to join and maybe contribute a bit, but it's kind of, I don't understand how we try to split the community between JavaScript and TypeScript programmer. Maybe it's me who oversimplifies stuff, but for me, if you know how to develop in JavaScript, like you know how to develop in TypeScript, it's not like a crazy change. So I would think it's a good benefit for the community of maintainers to switch to TypeScript. But of course, I just joined this discussion, I'm new here, so I don't want to, like, I'm not one to voice, I would say. But yeah, I think you, Lance did a great job of looking at TypeScript, and I think the next step is basically to just migrate. My advice would be, like, just go for it, but that's still up to you. As an end user, I think what he proposed would be enough. Okay, thank you. Lance, your hands up.  That's true, unless you don't actually know what those superset dits are. You know, you can write all the JavaScript in your .ts files, that's totally fine. But like, there's code in the SDK TypeScript repository that is not, I mean, it's part of that superset, and that's what I'm trying to avoid, at least for the short term.  But if you're doing JavaScript, here's the path you use, and it's more of a bundling step. Does that make any sense? Is that more confusing to people? Because I still can't wrap my head around whether there actually would be common code that would be used at runtime, and it's more of just a development build time difference. Does that make any sense? I mean, it's all the same, all just running JavaScript in node in today. It doesn't really make sense to have the same implementation of a spec in two different folders in the same repo. I mean, ideally, there'd just be TypeScript, and it would just compile to normal JavaScript, and that would just be one folder. Lance, your hands up. Oh, sorry, that's old. Oh, it's old? Okay, sorry. Yeah, I do agree with Grant. Yeah, I mean, it's literally like a block, like I don't know what to do. It's a blocker for tons of projects, including Google Project, and like there's been discussion about personal compromises and like adding tooling, but I don't really see that working. I don't understand, like this is not done. It's very common to just write, convert your module to TypeScript. Yeah, I'm really sorry about splitting the community, and I don't want to do that, and that's why I've held, like, that's why there's been so much discussion, and I'd rather not just publish a separate NPM module, but I mean, it's literally a blocker, and there's no proposed solution for interoperating with other TypeScript modules, so I don't really know what to do at this point. Yeah, okay, Francesca, your hands up first. Yeah, so I'll say that I have a little knowledge about JavaScript versus TypeScript, but to me this looks like saying that you recreate a Java library from scratch because you want to have Kotlin bindings.  Because I mean, then creating, I mean, it's quite a lot of work to create an SDK from scratch. If I understood correctly. Well, the issue, sorry, well, the issue with, yeah, it is a lot of work, and that's why it's been held off for such a long time. Ideally, we don't have to maintain two code paths. One is the Type system, and one, which is either JSTock or some external interface type file, which nobody wants to write, or you just write TypeScript, and so, which is literally just the minimal way to write TypeScript is just to change your file from .js to .ts, and the tool TSC can auto generate type bindings such that you get some nice auto completion in your IDE. And so that was the first proposed change of, well, if we really don't like to write interfaces, which I understand, being able to understand TypeScript isn't as intuitive if you write some of the extra features, but if we simply just change the files from .js to .ts and introduce this watch or build command, then that's, then you're writing TypeScript, and you don't have to use any of these extra features, and your IDE will still work, and it won't really be any different than your normal developer cycle. Okay, Eric, your hands up. Yeah, I wanted to make few comments. I've been a bit vocal on there, and I've been trying to cut through. I've got a few years behind me in JavaScript. I've just started picking up TypeScript, but I come from type languages primarily. So the two options that seem to be floating around are that strictly JavaScript with a lot of type annotations in the form .js docs and other tooling around it could spit out the TypeScript types, and TSLint clearly doesn't have to care what the file extension is and can look at JavaScript as though it were TypeScript and analyze it. As far as I've seen, there's a little more volume in the code in order to provide some of that, and it would be a lot of duct tape, in a sense. The alternative that could potentially satisfy but still be a compromise would be converting to TypeScript, and then enforcing using the TypeScript linter that none of the, or at least a large set of the TypeScript constructs would not be used, and in that way maintain the JavaScript look and feel of the repository. I think something that Lance brought up that is an important point is that the JavaScript community is very large and tends to have a huge diversity. It's one of the on-ramps into programming for a lot of people, and if somebody came to the repo and was hoping to contribute but saw something that was really unfamiliar, that might put them off, and maybe that's okay. That might not be the greatest strongest expert in the world, but that is one of those things that would be an impact of switching whole hog to TypeScript using all the type annotations and all the strengths and capabilities that that language offers. Anyway, I just wanted to share that kind of perspective. Okay, thank you, Eric. Sergei, your hands next. I just wanted to maybe ask questions that was already asked but wanted to get back to it. Since TypeScript here is actually two topics. One is TypeScript definitions and another one is writing the SDK in TypeScript. Which one are we aiming at? Because I believe the real issue is that the SDK is hard to consume from JavaScript or from TypeScript projects because there is no type information at all. But I don't think that rewriting the SDK in TypeScript is the only solution out there as someone already mentioned, there is an option to just ship the type definitions next to JavaScript sources and that's what React Team was doing, if I remember correctly, before they migrated to TypeScript. But anyways, a few other popular libraries are doing. I don't remember that we agreed that it's not an option, so maybe we can reiterate on it. Before I get to Lance, does anyone want to comment on that specifically? I think when you say it was before they migrated to TypeScript is something good to know. Basically, the end goal was still to migrate to TypeScript and the code base was probably too big to do it in one shot. Basically, we have a couple of peers that show that you could do it in one shot on your repo because at the end, this repo is not huge. It's quite a small repo. There's not that many contributors, so I think it's more easy It wasn't the case for them. They were using Flow for quite some time and they did ship TypeScript definitions just so that TypeScript users are not complaining about React being hard to consume from TypeScript, but they were fine with JavaScript for many years before they decided to migrate to TypeScript. There's long stories. I don't think it's a good example of migrations, rather just the history of a project. There are many other projects that still ship TypeScript definitions without having to rewrite everything into TypeScript. We're having the same situation in Java world where some new fancy languages start appearing like Kotlin, Druys, Kala, and others, but I would like to ask people involved into this conversation, why not CoffeeScript? Let's say I'm a fan of CoffeeScript and I want to have CoffeeScript support in SDK, so why shouldn't we rewrite it in CoffeeScript? So, wait, wait, wait, wait. I'll let people speak up there just to answer Serge's question, but I think we're going to have a tangent first. Let me get to Lance, since his hand was up and he's been patiently waiting. So jump your hand up if you want to answer that particular question, but Lance, I think you're next. Okay, thanks. I just have a couple of questions and then want to address a couple of points. So, Grant, you said that Google won't use the existing SDK, is that they won't use it if it's not written in TypeScript or they won't use it if there are no type definitions? That's one question. Another question is you said something about you can't integrate with other TypeScript modules and I don't quite understand what that means. Does that mean if as a dependency for something in SDK JavaScript, we want to pull in some other thing that's written in TypeScript? I don't know what that would be, but we want to pull in some other thing. It seems to me that we could do that, right? Because once you do NPM install, what you're getting is the transpiled JavaScript from that dependency. You're not getting a TypeScript. Then the other two points I want to make. The JS doc part, I think we need to do anyway. I don't think that that is a burden specific to TypeScript. We need to have our code well documented and publish it. I kind of don't think that's necessarily a burden specific to TypeScript. That should just be something that we do. Then I think I already said this, but if we're just sticking to pure JavaScript for the implementation, what is the point of going through the transpilation step and changing everything to .ts file? What's the point of going through that transpilation if we're transpiling from JavaScript to JavaScript? Honestly, I don't understand why we would do that. That's where I am. Grant, I see there were some questions in there for you. Do you want to try to answer those? Yes. I think I captured five questions of the two questions. Okay. One of the questions is integrating with other TypeScript modules and another comment about when you end can install, you're getting JavaScript.TypeScript. For dependencies that are using this SDK, you are getting just JavaScript, but if you develop ... NPM has this feature directly within Node, within NPM, specifying your type definitions along with your package. Usually, these are auto-generated. If there's some other way that we can do that without using TypeScript, that is okay. That's what my PR does. It generates the type definitions. Then you commit the old definition. The thing that Grant was saying is correct. Basically, you see in the modification all the files going through, while basically, we don't really care. When you do a PR review, I don't see how you want to do it because you're going to have to skip basically all those files because you don't really care. That's kind of weird in the workflow, in my opinion. It's pretty straightforward to generate those at publish time when you're publishing the module and include them in the publishing. I'm sorry to interrupt. I just have to say one more thing. The fact that I don't understand everything that we're talking about is, I think, a good enough reason to say, let's don't switch fully to TypeScript today. I've contributed 20 substantive pull requests in the last two or three weeks. I don't want to spend all this time trying to figure out how to deal with TypeScript. That's why I'm proposing a graduated approach to this. I'm a developer with more than 20 years of experience. To me, it's sometimes a little confusing. Can we not just acknowledge that maybe not everybody has that level of TypeScript experience and that converting a repository over to TypeScript might just be a little bit alienating? Okay, I'm going to stop. Good question. Maybe I got lost, Grant, but I think that one of the questions in there was, does the SDK itself need to be converted to TypeScript or just support TypeScript that's sort of like an API level using my dumb terminology? What was the answer to that question? The answer to that question is, yes, if there is some magical way that can produce these type definitions that is easy for consumers and developers, then, yeah, sure. But literally, the authors of TypeScript do not recommend any such solution and they recommend just writing TypeScript. There will be plenty of bugs and dependencies that are not supported by any major contributors if we do go this other route of using JS doc to generate TypeScript because it's not used by 99.5% of normal... Grant, in my PR, I'm using the TypeScript compiler to generate those type definitions. That's why I don't understand why you're saying it's magical. It's happening right there in the PR. The whole point of using TypeScript... Sorry, the whole point of using... I'm so surprised that we're now okay with using the TypeScript compiler for a feature that's really meant to just support legacy modules of using TSC to generate types. The only reason... This was an issue three, four years ago when the world was only just JavaScript and people were migrating to TypeScript. It's so much easier to just change your extension and not get all the other benefits that you don't see with just using TSC with JavaScript. Okay, Clemens... Actually, hold on, Clemens, before you start. Grant, did you answer all the questions that you thought I was asked of you or did you have a little more to say? There are some questions like, why are we tense piling if we're just using JavaScript? There's a comment about, I've contributed 24 requests in 20 years of experience and it's sometimes confusing. I don't know, I could address those, but... No, let's take the original ones that you're asked. I think you probably address those, I think. If not, I'm sure someone will raise their hand. So, Clemens... So, Remy actually makes the point, just made the point in the chat that I'm waiting to make. And that is the struggle you guys are having seems to be... So, I have no opinion on the concrete matter, I have to say, and I'm neutral to it, so I'll just give you the observation. This is the same struggle that C++ and C have, where C existed and then C++ came around and then people were starting to do C++ things, starting with different kinds of calling conventions and then even without doing classes, people were writing C programs using C++ and all of the sudden stuff ended up being compatible. And where that ended up was that people were then starting to build libraries that were hard C++ and the C99 camps exists and they're doing hard C libraries and C++ and C, they do cross each other because you can use C instead of C++, but that's pretty much it. So, I do wonder, and that's been a struggle that's been going on for a while and I feel like that's something that we're living here, the TypeScript being, if you will, the super language that's the C++-like one and Java being the foundation beings like C, where that sort of incompatibility exists. So, I do wonder whether it's really just two SDKs, which might be sharing some code where there might be a core in JavaScript that the TypeScript implementation might use, but the TypeScript implementation might also just go and deviate because that's what's happening in C++ and C-land. I said, I'm not taking any positions otherwise, but that struggle will continue and you will keep pulling on either side. And if there's a JavaScript and TypeScript two factions with different interests, then forking into two different language implementations and accepting TypeScript as its own language might just make sense. Okay, thank you. Tim, Tim, are you there? I'm sorry, I forget. I'm sorry guys, I'm not really involved in, I'm just a user of both Java and the JavaScript SDK. So, from my point of view, for what it's worth, I work on Visual Studio code extensions where TypeScript is enforced and I use the library and I created my own data bindings like what the PR does. At the end of the day, I just want to say because then I have to maintain both the JavaScript libraries and the type bindings and they have to be in sync. The point that I'm trying to make is I decided to just use straight JavaScript to create the cloud events because to me, it makes no sense having the data binding separate as a separate library or a separate dependency requirement. That's all I wanted to say that from the user perspective, sometimes things are a little bit different where I have hundreds of dependencies. I just don't want to deal with this. When with cloud events updates version, I don't want to have to deal with the data bindings as well. So to me, it would make sense if it was TypeScript and then compile down to pure JavaScript, which if I wanted to use it in the browser, I can do as well. But again, it's just my opinion from this perspective of what I'm doing. But of course, other people might have a different perspective. That's all I wanted to say. Thank you. Eric, you're up next. To address the last point, something that has been broadly agreed upon as far as I can tell is that TypeScript types should be created and published. So that need for the consumers of the library to do any work is completely gone. I raised my hand to address the point that Clemens was making. And one of the problems is if you're using C and C++, then you do need distinct libraries because of the calling conventions and such. With TypeScript, it's compiled down to JavaScript. And so what would likely happen is that communities, if there were types published in both, the communities of TypeScript and JavaScript developers would consume both. If only types were only produced by one, then all the TypeScript would go. But the JavaScript would probably also split itself across. And one of the things that would then result is users would have questions and they would show up on Stack Overflow. And now we would have a bunch of questions asked about potentially incompatible implementations. And this is something that would be very public and very confusing and require a whole lot of knowledge around these decisions that are being made that really are impacting maintainers only and contributors as they come by. So I think that's really an outcome that we would need to avoid for that as well as reasons of the duplication of effort and other things like that. There does seem to be a pretty good set of compromise options at this point. And I have a pretty good amount of confidence that the group can work through that. Okay. Thank you, Eric. Lance, you're up next. Yeah. I mean, I guess my question is who is meant to benefit from a conversion to TypeScript? Is it the end user who's consuming the SDK or is it the maintainer? Um, for me personally, I feel like a conversion to TypeScript would today not benefit me in a positive way. This is why I'm proposing a transition that may not necessarily be 100% on the first step. Lance, when you said me, did you, were you speaking as an SDK developer or as a user? Yeah, sorry, as an SDK developer. Okay. Thank you. Like, I, you know, I don't really want to write my code in TypeScript and that's just a personal preference. But it seems like the important thing here is making the module high quality and consumable in a way that TypeScript developers are comfortable with it. And it does what they expect it to do from a tooling perspective, right? What, what the IDE is supposed to do and stuff like that. I'd like to think that the proposal that I put forth yesterday actually achieves that. And if it doesn't, can someone tell me how it doesn't? Okay. Before I put Grant on the spot, Oleg, are your hands up next? Yeah, I'll try to be quick. I know we have a very limited knowledge of JavaScript, absolutely no knowledge of TypeScript. But I think based on just observing it from last week and this week, the reason why we haven't discussed, we even have the discussions because there's some kind of implied relationship between TypeScript and JavaScript. Like we don't argue about JavaScript versus Java or C sharp or go or whatever. So maybe that's where the real issue is. I mean, we're talking about split of the community, but we're not talking about split of the community between Java and C sharp, right? So maybe we should just look at it as TypeScript and JavaScript, right? And, and be done with it because like don't, it's not splitting of a community. It, there's just two communities and you're free to go with, which are where you want to. That's, I'm done. Oh, Rami, I know your hand is up there, but I wanted to force Grant. If I give it's okay, Grant. Yeah. Should I answer this question? Um, so sorry, which question is it? No, no, it was, I think it was Lance. I think Lance was asking why is PR can't be a step in the right direction. I think Lance want to rephrase it. I mean, that's it. Like, in fact, in the PR, I say this could be a possible path to a transition to full TypeScript, but just not ready to go there today. Does it achieve what we want it to achieve for the end user for the developer experience? Okay. Um, so yeah, I believe I made some comments on the original PR. I was, I was happy to see the PR heading in the right direction. Um, so I think I mentioned earlier that it's quite weird using the TypeScript tool TSC, which is the TypeScript compiler to compile JavaScript to generate these type definitions. Um, I, I mean, I think it's in the right step. Again, one of the issues was I already created a PR, which seems like it was ignored that would directly have merge conflicts with this PR. And so like, why are we purposefully creating PRs that have merge conflicts? Um, um, yeah, great. Great. Can you elaborate a little on that? I understand the concept of merge conflicts. It's just your PR, was it to rewrite the SDK in TypeScript, or was it as a was your PR more of a compromise position, but it was just a different way of doing compromise position than what Lance is suggesting? Uh, so my PR introduced one, one file or renamed one file from index.dayout.index.ts and set up tooling, which is basically the same tooling as in the other as in Lance's PR of adding TypeScript as a developer dependency. Does that make sense? Um, I think got a little too low level. I'm just trying to figure out whether your PR would still allow a JavaScript developer, whether it's an SDK JavaScript developer or a user from JavaScript developer to, to feel like they're still using a JavaScript SDK. Yes, but I mean, the, the PRs are basically the same, really. I, uh, they both, I mean, y'all, there's like no interface changes.  If you're an SDK maintainer, you're still going to write your normal JavaScript. There's no code changes, really. Okay. Remate your hands up. Uh, yeah, no, just to go in the same direction. Like the thing is for me, there was like, there's only one community is like, there is just a JavaScript community. Some people use TypeScript on top of it. Some don't, but if you look at like how I would define the community is, is it, where are the packages are stored? And it's all on NPM. They are all using the same infrastructure. It's not like it's on Maven or there is a TypeScript different repository. It's using the JavaScript repository. So it's basically JavaScript is just a supersede on that. And for, for the number of contributors, what I do understand is like, I have no, no judge there, but on GitHub, I see that Grant is contributing also to that repo. So I don't know, like, you need to find a way to match together. I like the new TypeScript repo. Like I like the code posted by a grant on the side, which is in that case, a complete rewrite, but the PR I did on the SDK JavaScript is not a rewrite. It's like also a migration. But please find a way together. Can't wait. Let's get along. Okay. Eric, you're up. Yeah. I would ask that Lancer Grant interrupting if I'm wrong on the points I'm about to make. But as I understand it, at the compromise positions have effectively made it so that despite the choice we make, the user experience of a consumer of the library will not be different. Yes. I would say at the top level that Grant's PR is converting to TypeScript. And that was its intention. The, and of course, Lancer's is an approach to maintaining JavaScript and using the TypeScript tooling to produce the types automatically. Eric? Sorry. That's pretty much what I wanted to say. I think that what maybe to summarize, I think what we've gotten, the point we've gotten to is that there is a maintainer experience in terms of the approach taken to providing those types and then what language constructs are allowable. Fundamentally, it's a good position. We've made good progress, I think. Okay. John, your hands up. And we're probably going to have to call time on this soon. And I have a proposal, not just a proposal, but a statement. It's a John. So, so as I, as I wrote in my comments in the, in the read on GitHub, the, as Remy was saying, it's really one community as far as JavaScript as an ecosystem. Right. So, a split is, is materially different than the C versus C++ issue. Okay. They are, they are merged in terms of the, you know, what I was trying to get to is, I think as Eric has been saying, the Lance's PR using JS doc and TSC to create these type definitions, right, versus grants original PR, not just new repo PR, right, as a separate thing. They're, you know, it feels like it's 48% one way and 52% the other way. Like they don't seem very far apart. Right. And so what I've been trying to hear is, well, what's the material difference? Right. If we're going to put the constraint that the, the actual code in the repo, at least for the time being is limited to JavaScript and whatever we need to support type script usage with the annotations or the auto generated, whatever, like, like it, it, it feels like we're, we're, we're, we're, we're bike shedding on, on what's effectively no difference for the end user experience. Right. And I think, I think moving the ball forward, like, you know, again, I'm not in there day to day on the JavaScript either way. So like, not since I don't care, but like, what's the, what's that, you know, what's that swing of a couple of percent of the, you know, switching it to dot TS files and the regular TS flow. Okay. So you get the transpilation step, but you're, you're still, if you go the other way, you have JS doc and you're, you're doing the extra tooling to generate and package and all of that for the type script developers. Right. So I guess I'm missing why, why there seems to be such a, such a visceral dispute about what seems like a very small difference. Okay. I'll go to Sergey and then I'm going to ask people to comment directly on that question. Sergey. Okay. So I don't have another argument or anything, but I just wanted to state one thing. I checked the project state and I see that the project was not created by Lance. He just joined the development, but he did quite some contributions in the past few days or a few weeks and he was contributing value. I believe or I can be wrong here, but if the project being type script and Lance said that he has a very limited type script experience, he may not, he may not have decided to join the project and we would miss these contributions. And I question how many other contributors we may miss if we rewrite project in a language that is less popular than type script, even thought type script is very popular, but still. Okay. Thank you. Lance, your hands up. Lance. Sorry, I was talking to my muted microphone. I guess I just wanted to address the, you know, the question of, of like, why digging your heels in or, you know, why is this such a, you know, a big source of friction. You know, in Sergey, I think said a little bit of that, which is, you know, if this had been type script a month ago and I came to look at it, I would have, I would have probably not started to contribute to it. I'm just not comfortable with it. And I feel like in the course of the last two or three weeks, I did start like I will never do this. I will never ever go this way and have made a lot of concessions along the way. And all I'm asking for is a single concession to like take this a little bit slowly if we can still provide the end user experience that we're looking for, that typescript developers are looking for. That's not the question I'm actually talking about, right? Oh, okay. I'm sorry. In the thread, in the thread, we already got to the point where at least I think, right, not to put words in Grant's mouth, right? But my understanding, and I think Eric comments were echoing this is I think there was agreement that we're not going to just add all these typescript features into the code. It was exactly about this difference in the tooling, right, of basically JS doc plus, you know, the TSC hacking in the pipeline to generate things versus letting the TS pipeline do its regular course of business by changing the file extensions to TS and putting the link restrictions to keep it restricted to core JavaScript as the base language features. Yeah, I think that's an interesting point. Really, the difference is in tooling. So, okay. Anybody want to make a comment? Okay. So I'm not necessarily sure that either side is necessarily moved. And I'm kind of at the point now where I feel like it's going to just come down to a vote. And I guess what I'd like to ask, though, is between now and next Thursday, meaning the regular serverless working group call or Codvan's call, if Lance and Grant would be willing to at least continue the discussions they've been having on trying to find that middle ground in the hopes that maybe a miracle will happen before Thursday. But if it doesn't happen, then come Thursday, we'll just gonna have to take a vote and see what happens. I mean, that sounds fine. I'd like to say that we already started a vote in the big, long thread. I don't know how many months ago. And then Bobby said the trip wins although it's never enforced. And so I feel like even if we take a vote, like, will we all be on one way or another? How is that going to be enforced? Well, to be clear, in my opinion, the vote isn't within the SDK. The vote is within the cloud events. And I understand what you're saying, though, that you sort of had a vote already in the SDK. And as long as that decision was limited to just the SDK, then I would say, yeah, the Java SDK guys can do whatever they want to do. It's their repo. However, for better or worse, that decision or that vote was never executed on. And so we're at a different point in time, unfortunately. And now we're at the point where in order to keep the TypeScript repo, I think that that question is now bigger than just the JavaScript SDK. It has to be, I think, be answered by the broader group. So that's why I think it is a different vote. But, John, is your hand older new? It's new. Okay, go ahead. So to follow on your point, Doug, the question is, well, it sounds like there's two votes, right? One is more or less around what I'm trying to talk about is it seems like, to me, to simplify it, it's a question of do we go with JS doc and TSC hacking and keeping the extensions.js versus changing the extensions to .ts and tweaking the pipeline to enforce the source language staying JavaScript. That's the technical side of the discussion, which is I think where we're at. I think there's a separate discussion, which is what you're bringing up, Doug, is if, like, we blow up the whole world because everybody's upset on the technical argument, then there's a cloud events project level argument of do we support too heavily overlapping end user communities with having two different rebows? Yeah. Eric, your hands up. I was basically going to make, reinforce some of those points. Yeah, it's exactly that. There's a docs and public experience decision that I think is very much a cloud events discussion and decision. And then the tooling decision, I think, is something that only maintainers should make. Okay. So let me echo back what I think I heard you guys say to make sure I heard it right. It sounds to me like you're saying that within the SDK, within the JavaScript SDK itself, you guys need to figure out whether you can resolve it yourself, whether that's a vote or something else, you guys need to figure out whether you can resolve it yourself. And if you can't resolve it within the group itself and if you can't resolve it within the group yourself, then it has to bubble up to the full blown working group in terms of whether we're going to create a separate repo. Because if you don't resolve it yourself right now, I think you're going to go on the path you're on, which is grand wants a separate repo and he's asking for that. And if he doesn't get a resolution in the JavaScript SDK, that he can live with, I assume grants request is still going to stick, which means the working group itself has to resolve his request, which is a formal vote, in my opinion. Does that make any sense or I've completely messed up my words. I raised my hand again. Okay. I would say that if the problem is that I think there's fairly broad consensus for the group, especially because of the ecosystem that to repositories is not a good outcome. That's problematic. In a sense, I think I don't think I can say this in total good faith, but I think that the decision of the cloud events group would be that these two have to figure out how to live together. And we would very much hope that it's peaceful and that everyone's needs can be satisfied. Exactly how those needs get satisfied. I don't think the group has a lot of most of us aren't maintainers and won't be impacted by that. So that the vote would be whether the external community is impacted based on whether there are two repos or one. I guess I'm trying to figure out the concrete next steps here, right? Because it seems to me that we can't let this decision linger for much longer. It's been out there a while. Actually, John, is your hand up new rules? It's new. Go for it. So I've tried to channel Doug to help corral this, right? Is it fair to say, for both Grant and Lance, as the champions of their respective groups, that the argument, as of right now, is really what I said before, right? It's JS doc plus TSE hacking on the pipeline and keeping everything .js extensions versus changing things to .ts and the regular ts pipeline plus the lint restrictions. And if that's the case, can we focus on that as the move the ball forward argument under review? And can we flip a coin, whatever, beat each other up and just pick one of those two and move forward? Grant, your hand's up. Yes. I'm not really clear on, so how are we going to bubble this up? So what are the sides? I know we're sort of trying to figure that out right now. So we're going to have a vote on that, right? We're trying to figure out the next steps. And I think we're trying our best to keep it within the Java SDK sphere first as best we can. But if that completely fails, then it has to bubble up to the full cloud events group, I think. Can I ask Lance a question? So if we had, for example, a vote in the working group that voted for TypeScript support, full TypeScript support, would that be respected? Well, Lance, don't answer that yet, because I don't think that would be the vote. The vote would not be convert to the JavaScript SDK to TypeScript. That would not be the vote. The vote would be, do we create a TypeScript SDK? At least I think that's what the vote would be. Do we create a TypeScript SDK? Then if the vote is denied, I guess what is the expectations for the non-majority that want a TypeScript support, I guess. So if, for some reason, this bubbles up to the cloud events SDK, I'm sorry, the cloud events group for the TypeScript SDK and the vote fails. Then we kill the TypeScript repo and normal GitHub repo process rules apply in terms of when PRs are merged versus rejected. And you guys in the Java SDK need to figure out which of the two PRs live on, if either. Okay. Lance, I think your hand's up next. Yeah, just a couple of things. John, I wasn't going to say it the first time, but I have to say the second time you said it. I don't think my solution is hacking the TypeScript compiler. It is a documented way to generate type definitions from the TypeScript compiler documentation. So it's not hacking. When we talk about TypeScript support, Grant, you mentioned TypeScript support. That's one of the questions I'm trying to get to is what does TypeScript support mean? Does that mean that for the end user, for the consumer of this SDK, they get the type definitions and all of the stuff that you have there in your screenshot from the IDE, if that's the case, well, then both of our PRs solve that. And then the last thing is, if we go to like the, you know, rename everything to .ts, everything goes through the TypeScript pipeline, but we add these linting rules to ensure that we're just using pure JavaScript, like what does that get us? I don't understand why we would go through that process of a translation step before we can publish or before we can even, you know, do something in the node CLI to test locally, you know, as we're writing code. Like if we're just writing pure JavaScript, I don't understand why we would need that translation step. Okay, we're running out of time here. So John and then Remy, I think at that point, we're gonna have to probably call it quits. Yeah. So, at this point, I'm agreeing. From my understanding, like whether you call it a hack or not, fine, that's on me, but that's what I say. I think that the Grants Original PR and your PR are literally like 48 one way versus 52 the other. I think it's solving these end user issue types and annotations and code completion support and those sorts of things, right? So I think the forcing function is we should just resolve to pick one of those two as the step to move forward and go from there. Is that possible? Lance and Grant. Grant, does your PR actually provide the core JavaScript enforcement? So I think if we're going to go that route, we should probably make sure that it does include what is up to date in the disk. My PR simply introduces the TypeScript tooling, which Lance also introduces and it renames one file index.js to index.ts. Just to prove that it's literally the same code. We can add this enforcement if we want to and developers developing the TypeScript or the JavaScript library will be writing the same code and it won't impact end users at all. That's the difference. Okay, Remi, I think your hand's up next. I'm assuming Grant, your hand and Lance, your hand are old. Correct me if I'm wrong though. Yeah, I'll try to be quick. I was rereading the full thread on issue nine and I'm just surprised because I would like to have information from the old contributors because for now I only see two new contributors that are fighting against each other. Sorry, I'm French. That's the way I feel it and I have seen that there is Fabio, José, there is Brazilian or there is other people that could probably have an ID and when you look in the thread, I do understand what Grant refers to when he says there was a vote in August 2019 where basically Fabio José, who is basically the biggest contributor, was saying, okay, be wins and let's go. So I do understand why there is some frustration from Grant now, like maybe I didn't read enough before, but it looks like they found a solution together just inside that repo and then it was brought to that broader audience. So again, at the end, whatever, if I can contribute, it's fine, but I'm not consider myself as the main contributor. So it's just the other contributor, I would like to have understand what is their opinion because it's not only Lentz or Grant who contributes to that repository, most of that repository was not even built by them. So I'm surprised. Yeah. So Grant, I apologize. Sounds like your hand wasn't old. Yeah. No, it's okay. I've been raising my hand. So yeah, Fabio, he just committed to master hundreds of commits. And as you can see in the original issue nine, he is okay with converting to TypeScript after bedding. I've talked to him on Slack a bit. He served Seaman different. And that's that. Yeah, I don't know why he doesn't contribute anymore. And now, yeah, I feel like it's me and Lentz talking. Okay. So is it possible to come to a resolution on those two PRs in question before end of day Wednesday next week? Either merge one of them, find a new solution, it merges the two of them, kill both of them. Is it possible to resolve those two PRs before Wednesday? Because to me, if you could resolve those two PRs, either accept or reject one or both of them, then that would be the answer of the SDK, right? Either you found a solution that you could both live with, or you could not find a solution. And then things are going to bubble up to the full cloud events working group for a decision. I mean, I created a PR seven days ago that introduces TypeScript in the least possible way after talking and basically after request of, well, just show me the code rather than talk about it from Lentz. And I don't know why. I mean, it was a review, I guess, 21 hours ago. But then different PR conflicts with it from Lentz. And both, like, if you want me to just close my PR and go with Lentz, it's a step forward. But I don't, like, there seems to be politics or some, I don't know what. So let me be clear. I'm not going to get into the process of that stuff. What I'm asking for is from you guys on the call or the people in the SDK group itself to find a way forward here or come back and say we can't and therefore we toss our hands up and now it's for the work, it's for the CE group to decide. And if you guys can come to a resolution on those two PRs by next Wednesday, I think that's going to lead to the next step in the process. Either you came to a resolution and a PR was merged and you're both happy, great, then there's nothing else to be done. But if both PRs are rejected and the issue is still there and grant you still want to have a TypeScript SDK, then okay, then the CE group will vote on whether the SDK, a new SDK should be created on. I'm just asking for you guys, whether it's you too, or the group at large to go off and by next Wednesday try to come up with a resolution. Because by next Thursday, I want to have a vote. If a vote is necessary and be done with this. I know that's blunt, but I don't think it's fair to anybody to let this thing linger on for much longer, especially when I don't hear either side necessarily moving. Okay. Well, I don't think given the introduction of a new PR yesterday, that intention of cooperating and so I don't think there'll be any progress. Okay, Lance, you're up. So I mean, I guess I don't feel that's very accurate. I think that PR actually is a representation of my ability to compromise and the fact that I've learned things over the last couple of weeks about what TypeScript can bring to an end user. And I feel like it creates that end user experience that we want while avoiding the potential alienation of me and one or two of my colleagues who are also contributing to this repository. So in terms of finding a middle ground, I honestly feel like I've taken a few steps towards that middle ground and have even stated in the PR and in other threads that this is a possible path towards full conversion to TypeScript. But I'm personally not ready to do that right now. I'd like to see you, Grant, take one or two steps towards the middle ground. So, okay, well, over time, I think we need to end it. Let me just say, can you guys, I know it's gonna be painful to ask because I know there are strong feelings of both sides, but can you guys please try to have some offline conversations and I don't mean through GitHub issues. I mean like voice communications to see if you can understand each other's position better, find that middle ground or something because I just feel like in nothing else, at least a voice communication will at least have faster communication turn around than going through GitHub issues. And see if you can find that middle ground position because I mean for all I know, John is right. You guys really aren't that far apart, but for some reason you're not seeing it. I don't know. We're not that far apart. I've taken a bunch of steps towards Grant's position. Well, okay, so can you guys take it offline and see what you can do in terms of working or trying to come to a resolution? I know Grant has been very frustrating and there were several times when you said, you know, you're done, you're frustrated and I get that. But as painful as it is, if you can possibly come to a compromise on both sides that you can both live with, not saying it's ideal, but you can at least live with to see how it plays out. And maybe one or both of you will be surprised that, hey, it actually isn't as bad as you thought it was going to be. That might be the better solution than creating a home of the repository right off the bat. I agree. I don't think we should create another repository. Well, yeah, but I mean, it's easy for me to say that we shouldn't. I mean, I don't think we should either, but I'm literally blocked and I can't answer my product manager and figure out a dozen other issues with this package. Okay, so damn, I really need to go to another call. You can get to a different call. I don't know if there's anybody else here. We can just talk. Yeah, you guys, this zoom will keep going. So you guys, if you're free, you know, keep talking, but please find some way to talk offline if you can, if not on this cover here, but try to find that middle ground if you can. And then I'll ping you guys offline later either today or tomorrow to see what happened and see if anything was made in terms of progress. So Grant, are you sticking around? Yeah, I can stick around. If I can interrupt, I'll stick around for a little bit. I do think that Lance is correct. I think that what his PR represents is his understanding of some of the compromise ground that's been discussed. And certainly it's clear, sorry, Grant, that that's not your preferred. But it does make concrete and specific what it is that we have been discussing in the threads. And whether it's the right option is separate. I think that is, I think basically Lance has been showing good faith. So I'll just start by saying the concerns that I have with, and these are all things that we've said before, but I just want to say them vocally. The concerns that I have with moving fully to TypeScript right now are that myself and other Red Hat developers are not TypeScript developers. And if we say that, okay, well, you can still just write pure JavaScript and we're going to enforce that with linting rules, then I don't understand what the whole point is of running the transpiler to convert JavaScript to JavaScript. I mean, I've said that a number of times on this call. For me, at least as far as I understand it, the big concern is the end user experience. And I don't really, I'm not clear. I think that what I've proposed is gets us to the same end user experience and is a step towards getting what you want, Grant. It just doesn't mean it's happening tomorrow. Yeah, so I mean, it's definitely an improvement. Again, I think one of the issues was I proposed the same improvement seven days ago and then I didn't know exactly, like... Well, seven days ago, I mean, I clearly and still have some issues with that repository and I felt like I wanted to express what I thought might be a good compromise through my PR. And I mean, come on, submitting PRs is like that may or may not conflict with other PRs. That's just open source programming. That just happens. This is not understandable. But I feel like this is just going to lead to more issues if there's a situation where just because you're not familiar with the tooling or are making a lot of learning a lot from the tooling, doesn't mean that you have to sort of hijack the initial step of getting TypeScript support and not accept PRs. Well, when you say TypeScript support, what do you mean? Are you talking about for the end user? I don't think that you're representing my position in good faith again. I am absolutely trying to provide TypeScript support. If I might, from the repository's standpoint, especially because it's the official repository of the group, the point is not actually about Lance. Lance is a convenient voice and an advocate, but it really is about the far larger set of JavaScript developers that don't feel comfortable using TypeScript. Now, I've been pretty mum about it, but personally, to make this decision for myself, I would go with TypeScript. I'm comfortable changing languages and done it a lot, and I feel like everyone I learn, I learn a lot of new things. So that's where I'm coming from. But I think it's not a small point that a number of developers who might become contributors would feel excluded if they came into the repository and saw something that just wasn't part of the warehouse, wasn't comfortable and familiar to them. Now, that is not the greatest way to make decisions, but it's also a very pragmatic concern. And I got to say that of the things that has surprised and delighted me the most in getting into the JavaScript ecosystem is the deep level of pragmatism that is present. Just the amount of cruft that the community is going to put up with in terms of all the, back in the day, detecting what browser and then writing different code lines and for dealing with certain things in different browsers and just all of that garbage that you just never had to deal with in more types of spaces. It's been a space of bad compromises and a lot of pragmatism, and that pragmatism has created a lot of value and clearly there's a lot of, you know, at stake and revenue and everything else in the way that has led to that. But it would be a big thing to say that that community is not welcome. But I think if I may, the switching to TypeScript doesn't exclude the JavaScript developer, like in my opinion, it's not the case. And we are like, I hear you referring to like potential contributors, like basically, if I had a preference, if I see the two PR, I'm sorry too, it's not going to be nice. I don't have a nice way to say that, but the lens contribution is not as sexy, it's not really clean. So if I come as like a contributor, I will be less inclined to join the repository because for me it's less clean. Maybe it's, I'm the, it's just my own opinion. So I don't want to say that I'm not claiming or present anybody else. It's just I'm more inclined to work on a clean repository that's something that starts acting, because it's kind of a act, it's still kind of a act. And it doesn't have the feeling that it's a clean repository. What do you mean by clean? That's like, what would change? Whether I will say clean, it's really not like, I don't want to say that I'm the one knowing what is clean or not, because I think it's really a subjective opinion. But when you look at other projects like TypeScript and JavaScript project, the way they are, what you expect to see in a repository, it's not going to match exactly with your PR, because I will not expect to see those kind of acts for TypeScript. It's not natural to me, like if you look on the other TypeScript or JavaScript project, I know. So again, like I'm not pretending I know all the projects, but it doesn't, it doesn't have the feeling to be like cutting age repository. And that's just my opinion again. Is that because it's the PR specifically is just generating type definitions and we're not dealing with TypeScript? Or is that the like layout of the repository and code choices and things like that? It's a bit of both. And again, like I didn't contribute so like I don't want, like I would not specifically like myself if I were you hearing what I'm saying. So, because it's I'm in a weird position. I haven't contributed yet. I'm trying to understand and trying to help. But without contributing, my position is a bit weird. It's just, yeah, like I was looking at the PR that granted and it had more that feeling. So that's that's why I'm express my preference there. Well, I would agree with you in terms of how, you know, the repository is laid out and some of the choices in the implementation. You know, I would have made different choices if I had written that back when it was first started a year ago.  Again, I'll just say like, I'm not 100% comfortable with it. And I'm proposing this as an alternative possible step towards moving in that direction while at the same time trying to solve the concerns for the end user. Yeah, what I'm amazed to be honest, like the following this call and thing like that is, I think you have like a good community. Like if you have issue you with TypeScript, I don't think that grant will say like, I'm not gonna explain you the few things that I need to explain. Or even myself, I can spend a bit of time to do the same kind of thing. So if you think as a team and not as an individual, I think the team could do and like the migration to TypeScript and do it efficiently with help. So that doesn't mean that you can do it on your own. I don't think that you will be on your own. That was that the feeling I get from those calls is I'm quite surprised like there is a good community and like people speak together. So I would expect you to be able to reach for some help if you need some. Absolutely. I mean, I think so. I also think that I would like to take it slowly. You know, maybe maybe on being irrational. But again, like I said a few minutes ago, I do feel like I've made a lot of concessions and and tried to take steps towards the middle ground. And I am speaking to some extent for my colleague Helio who has no experience with TypeScript and has expressed reservations. And you know, that's just where I'm coming from. Yeah. I definitely feel you Lance. Like there didn't exist this TypeScript thing. And like most languages and new technologies, I and lots of people don't like adopting them without a very good reason or looking at them. And I really appreciate all the different levels of conversation. And even using some of the TypeScript like legacy tooling of generating types from JavaScript. I mean, it's not, I shouldn't say legacy. That's less conventional these days.  Like software is literally like five years from now, it doesn't really matter who has an end user who wrote the software. Like for me, this highly affects my work because I'm trying to support a product launch of an event system at Google. And JavaScript is the most popular language. And I literally can't do that. And I know we're getting there. But I feel like, especially with the most recent PR that they're like, there's an unwillingness to work on a PR together. I and I will just create more and more complex. I mean, I can go and close my PR and and like say, okay, yours looks good. But like, it's just creating it's creating a really unhealthy relationship. And I feel like I have so much I could help contribute and and the people that I know at my company that can contribute to this project. But if if there's a resistance to just like learning TypeScript or or accepting PRs or making progress in a timely matter, I really need to spend my time elsewhere and focus on other languages. So I guess, you know, I don't know, I kind of have a lot of questions like it sounds to me from from what you're saying that that the expectation would be not actually to have to restrict it using renting rules to pure JavaScript. All right, no, I'll I'll I think it's really it's most important to work with all contributors and make everybody feel comfortable. I don't think it'd be wise. I mean, I could like create a private repository and have my TypeScript SDK and just create PRs for that. But I don't think that's going to be really wise, especially for the community. I really have technical a technical reservation. I don't think that these added extra lip. I mean, we can definitely enforce the just use JavaScript, but renamed to TS. So we get all the extra tooling and goodness with that. What is that tooling? It's TSC. And it's visual studio code with the language server that understands the file type.ts. And so how does the generation of type definitions not get us there? Well, the generation of definitions, you won't have types. It won't be with JavaScript. It does not infer types. But with TypeScript, you can infer types. And that's real useful for autocompletion for JavaScript, or TypeScript developers. I'd like to see that because basically everything I've seen is that using VS Code and type definitions in this repository gets me all the way there. And maybe I'm missing some other thing that my IDE might be able to do if I'm So, yeah, VS Code is written in TypeScript. But for the language server for VS Code, it will do the very best. Well, basically, in the background, rename your JavaScript to TypeScript because all TypeScript is about JavaScript and there's extra tooling. And it'll provide a very similar IDE experience even if you use the .js extension. I guess I still don't understand what the benefit, like if you've got the type definitions like to the end user, what is the, like, to me, it's what we're arguing about is what the SDK maintainer experience is. Because I don't, I have yet to be clear on what the end user experience, how it would change if we did more than type definitions. Once you're right, if everything's perfect, it's all you're doing at the end of the day is just running some JavaScript in Node. But unless you have, you show me an excellent case study of someone using this, I mean, I've said it, and I'll still say it like other people have said it like a hacky solution of using TSC for compiling JavaScript and using the legacy autocompletion and not ideal cooling for just pure JavaScript. If you provide the same developer experience, that's great. The easiest way to get that developer experience is just to rename our files to .js. We can add like read only fields and like all sorts of great extensions that are beneficial, that use TypeScript features at a later point, if you really want to, to provide even better cooling. But I literally don't see, like, show me any company or any, like, every, pretty much every company, major companies use JavaScript. Show me any company that uses this other just JS way of enforcing types and just pure JavaScript and creates such, creates a modern IDE. I just don't know of any tooling like that. I'm really confused, to be honest. I mean, like, it sounds like we're talking in circles. Like, you keep saying legacy.  If we get the same experience for the end user using type definitions, why is that bad? So I'll say this again, like, it's the same. You'll get, if you can magically create an SDK that has the type definitions, there is no difference. You're right. But it's not magic. I mean, it's there. I'm doing it right now. It's already happening. And what you said about, like, changing your file names to .ts, I mean, that's doing exactly the same thing, right? It's generating type definitions from those .ts files. And then you transpile JavaScript from JavaScript to JavaScript, which seems silly to me. If we take the first step that the TSC does in your implementation, which is generating those type definitions and stop there, can't that just be, like, a step along this continuum? Yeah. I mean, they're both, they're both, both ways are steps, but you're just taking, like, you need two steps rather than my solution just needs one step. Well, your solution needs two steps in other scenarios, right? In order to, to, like, run. Like, literally, you can just ask the TypeScript authors what they recommend. If nine out of 10 of them will recommend just using TypeScript, like, I don't know why are we using the tooling, but not the actual language? Because you demanded that we needed to have type definitions. And I agree. Like, it's fine. It's great. We want to work with TypeScript. I don't understand why you can't accept a step in that direction. A step. It said I can go and close my PR and just approve yours and, or I could just abandon any involvement in this project. But that's not going to be ideal. Like, there are other issues besides TypeScript definitions in this project. I agree and I'm trying to fix them for three weeks and not have this argument. Yeah. Well, this SDK has been around for two years and I didn't get involved because there are commitments to master. And I don't, I mean, like, if you say, Lance, like, all these other issues will be solved and I'll figure out that definition. And he provided that to end users by, like, next quarter. Like, I just abandoned being involved in these discussions and I'd be happy. Like, I understand your willingness to be able to adapt to that definition. That'll satisfy the end user's needs. If I'm a contributor, which I hope to be able to, like, make any contributions, any developer experience improvements in next year, it'll be a lot harder for me to just like, it'll just be a lot more code. And I don't know if all the extra tooling will be great because it's not as maintained by JS doc. And so it's just a bit more of a rip. I have a piece of ignorance there. Is there an alternative to JS doc for providing that kind of IntelliSense knowledge about how to use something in its semantics? Well, I don't think JS doc is providing the IntelliSense. I think what's happening is, and I could be wrong. Grant, you can correct me if I am. I believe that TSC is using the JS docs to help it infer types. If the JS docs aren't there, it'll still try to make inferences. But the JS docs help to sort of solidify the inferences that it's making. I think. And your question was about, is there an alternative? No, not really. I mean, the code documentation ecosystem in JavaScript is not great. For answered, just a generic question about type definitions in JS doc at all. I would guess that JS doc does not affect the type definitions. I think the type definitions are just considered as a usage of the JavaScript within the library. I'm not sure. Because a type, a single attribute can have multiple types. If you mess up your doc or forget this can be a string and a number, that will be, I guess, that will just be either inferred from your code or the JS doc and go into the type definition. Anyways, I hope that added something to the conversation. Thank you. One concern, this is definitely a developer concern, but that I don't understand how we're going to solve is, are we going to enforce the, make sure that JS doc is right, 100% right, basically. There's some tooling I think you mentioned that we can do that. How does, how do we even, like, that's the way TypeScript, like TypeScript is drawing enforces type definitions all the way down, type, types, I guess, all the way down. Sorry, was that a question? Yeah, so I guess, like how, so we're, we're playing to use JS doc, right? We already are. I mean, JS doc runs in the While we're planning to, specifically, we're planning to use JS doc to generate TypeScript definitions. No, we're using TSC to generate type definitions. But you mentioned that TSC might use the JS doc. Is that right? I think that TSC might use the JS doc to help it make inferences if it's, if it's not clear in the code, or maybe it starts with the JS doc. I don't know, I don't have that branch checked out on my repo right now. I've got some in flat work, so I can't test it at the moment. But if I recall correctly, you like, you change the type in the JS doc and, and but don't change the, you know, the code type TSC will complain, but I need to confirm that. Okay. Well, so then the question to follow up with you, Grant, then if in a pure TypeScript environment are docs written in a TypeScript specific format, right, or is this JS doc really an orthogonal issue? No, I mean, JS doc is used in TypeScript. There's really not that many differences between TypeScript and JavaScript. Yeah, that's my, that's my understanding, right, from what I've, but that's, that's my question, right? Because I guess my, what I'm trying to get to is teasing apart, like, okay, if the JS doc is really just a documentation issue, right, then, you know, we can sort of get rid of more, more of this extraneous things to try and cleave to, you know, what, what's the real distinction benefit of one side of this line or the other? All right. Well, one of the issues is like, so with, with JS doc with TypeScript, you do not have to annotate the types because it's automatically inferred by the tooling. That's one great benefit where you can have less code, less comments, and have the tooling just automatically work. And it'll, and it'll work at, like, when you're writing your code, such that you're trying to call t-string on a calling like. Well, so let me jump into that, right? So again, I don't use BS code JavaScript. So is this sort of the difference of, hey, we're, we're using Lance's approach is using the TSC compiler and first stage or whatever to get that information. But it's basically a batch process versus BS code is doing it fully dynamically as you're, as you're going, right? Is that, is that a difference in the experience? Well, you can, you can generate the types. Again, the issue is sort of while, while you're developing the SDK, if you, I mean, any user will eventually get just the compiled script definitions and the node module such that it won't make a difference. But I'm, I'm not super familiar with writing, actually, this writing JavaScript anymore with the IDE experience. But, but with writing type script, you'll get, well, first you'll get enforced types. It'll always be accurate. Like, so if you mess up a JSTock, it'll never JSTock comment. Like it doesn't use those. It uses the types directly from the source kit, not from the comms.  It's, it's IR or whatever, it's being the JavaScript as, as types from its perspective, even if it's looking at a .js file, right? So that's why I'm trying to get to what's the, what's the difference in not experience, right? Is it inhibiting you from, you know, is it inhibiting BS code as the example from doing refactorings just because it's a difference in the extension of the file, right? Or, or is it going to do the same inference? Yeah, I'm not familiar exactly with what features there are with JavaScript, actually, because I haven't written, I usually write TypeScript, but you can do refactorings like rename a member field throughout the file, throughout all the tests everywhere, and they'll always be completely accurate. You can move classes, you can move functions, all because your code can be safely typed. I'll take up a little bit from the JavaScript experience on this particular subject, because refactoring is kind of one of the big pieces that TypeScript seems to pull ahead on. And the difference is in JavaScript, you'll probably get a pretty good refactoring, but it's possible that there will be mistakes, and you should check that and take a look at where the IDE is suggesting changes should be made because they will not always be correct, and a lot of the time it's based on string searches. Whereas with TypeScript, you get a guarantee that it will be correct because it knows exactly. Well, so let me let me dump into that. That's if you're using TypeScript for actually typing, right? So if you're writing just plain raw JavaScript code without the types, right, in a file that's .js versus .ts, like doesn't have the extra information. Is that correct? Right? It's still going to be doing the same analysis because it doesn't have the extra type annotations. That's how I understand it, which is kind of why, like, I'm reluctant to go with Grants PR because it seems to me that here's in mind both achieve the same thing, but that at least initially, like I don't see that there's any improvement or any benefit to changing to .ts files unless you plan to use the TypeScript superset of, you know, the language. And, you know, I thought that we had talked about not doing that. I see. So let me ask you, Lance, a timeline question, right? Because part of your thing is, hey, it takes time to learn TypeScript and all of that, right? I don't know how to ask this in a more neutral way. So forgive me. The group of developers that you're representing, right, is the long-term concern. Let me state it that way, right? So think a year from now, right? Are you open to evolving the SDK code base over some longer period of time to start adding more of these extra features, assuming that they're good and useful and all of that, right? Or is it more of a, we want to keep it pure JavaScript forever? Or, you know, indefinitely? So I guess I would say, I mean, I've said in the PR that I see this as a possible step towards a transition to full TypeScript, but I keep saying possible step because I'm open to it. But, you know, I'm, I can't say right now, yes, absolutely. I'm going to, once I get all this, you know, the type interfaces and stuff figured out the superset of the language, and I learned that and I'm comfortable with it, then great. I, you know, I'll move in that direction. Yeah. I mean, does that answer your question? Well, so I guess I'm trying to tease into, you know, whatever you want to call it, a philosophical foundation, right? There's some, there's some people who are like, whatever the language is, I'm a C-Permimer and I'm going to use C++, right? And, and, you know, then they go to work for some place that it's using C++, but just some very specific subset, right? And they're okay with that, but they're not going to do all the run time insanity in C++. That kind of thing, right? So there's, that there's that kind of middle ground versus, hey, you know, it's just a matter of time, see the benefit, we can see the TypeScript community is kind of, you know, eating the JavaScript world because there really is some problems or whatever. And our issue is really just we don't have the time and, you know, we're not experts and so we don't want to just jump into it. I guess is what I'm trying to tease, tease apart. Well, I'll speak for myself personally, the, and it kind of goes to the comment I made very early on in this call, is that I feel like I've been extremely productive over the last three weeks. And I think if we start introducing things like interfaces and stuff like that, that's going to slow me down pretty dramatically. If we start introducing that stuff immediately. Okay. I'm not a, you know, I like I have, JavaScript is not the only language I've ever worked in. I've switched programming languages a lot, you know, I've done Java, I've done Plus Plus, I've done Perl, I've done JavaScript. I mean, I'm not afraid of new languages. I don't particularly like TypeScript. I don't like the way it looks. I like JavaScript for the, you know, dynamic nature of it, the loose typing. But I get it. Other people like strong typing and that's great. You know, just because I don't like it doesn't mean it can't be a part of the project. Right. So then let me, let me put in another hypothetical. Right. So, so let's, let's, let's, let's hypothetically, let's start with, okay, so you have this PR with the JS doc and using TSC or whatever. And we go with that. Right. And then three months from now, or whatever. Right. Some not too distant future. Somebody comes in a PR that had some of these early things where they've done all the work. Some of these early thing, what do you mean? Whatever. Interface definitions, adding more typing, right, whatever, you know, some, some, you know, where it doesn't completely wholesale change the, the, the, the JavaScript, but it's, call it additive. Right. Where it's adding some capabilities and they've gone in and cleaned up and, and they've, they're, they're already types of experts and they've done all the work. They've added tests. So it's all, it's all verified and tested. Right. And it's three months from now. What, what do you, what's your, what's your take on that? Let me make sure I understand the scenario. So we've, we've merged my compromise PR and we're not actually doing transpilation step. We're just doing type definition generation today. Yes. Every month from now, somebody comes in with PR that has a TypeScript interface and also modifies the build pipeline so that, you know, it's working that way. And they've done all the work. Right. And they've tested it and, you know, all of that kind of stuff. Right. So they're, they're not, they're not burdening you. Right. With any of that extra work to make that, to make that PR. Yeah. I mean, it's hard to say in a hypothetical. If it's somebody coming in from the outside who's not a maintainer and won't necessarily stick around to maintain it, then that might be a little question. Yeah. Okay. Well, so then let me, let me embellish the hypothetical and say that it's grant or grant team. Right. That they're using it for a product. So you have some, you have at least as good as most anybody else. Right. That they're going to, they're going to support that for, for a reasonable amount of time. Right. And they, they know what they're doing. Right. That, like, their people have a clue. They're, they're, they're committed and, and, you know, they're willing to, we're willing to back what they get. Yeah. I mean, and if, if they could help me understand what benefit it brings either to the end user or the SDK developer without imposing burden, then I, yeah, I mean, I'm a reasonable person. I know it may not seem that way based on some of the online discussions, but I hope that my actions in trying to compromise here sort of illustrate that I'm not like unwilling to bend. Yeah. I'm just trying to help, right?  So I'm, you know, trying to use the hypothetical to try and give some, give some flavor to that, you know, to, to, in that sense, both, both camps, that a decision today is not, is not like, okay, now we're in a street, and we're stating this, okay, this is not a policy forever. Right. For the sake of establishing a philosophical basis, I think it might be also important to ask the related question, which I think Lance has already commented on. If this repo was written in type, say this hypothetical grant to rose this beautiful PR was very one well done, all the support long term committed. And that was merged. If a Lance to came along, having been steeped only in JavaScript, and was looking at the repo and thinking about making a contribution with that, with Lance to be willing to kind of absorb some of the new environment and constructs in order to make that contribution. Yeah. That's a question for me. Would I be willing to absorb? Is that a question? Well, I think, I mean, given my willingness to flex on all these things, I don't think I can make a good assertion because I'd be fine. But certainly, given the stance that you've certainly started with, and as it's evolved, I think you could probably speak to the more general case with more authority than certainly I can.  So if it were all in TypeScript, I would probably not have contributed. I don't know. It really depends. I mean, it's like we too are using this in a potential product down the line, we being Red Hat. And so it may be that I would have had to just because we need to use it. But I would have been reluctant. I mean, I'm not a TypeScript developer. When I look at early in the thread about the TypeScript types thread, number nine on the issues, Grant, you link to the, you know, a Google interface for pod events. And, you know, that's just like I looked at that and I was like, Hey, that's not JavaScript. That's not what I'm comfortable with. Yeah. So I guess in the general case, yeah. Obviously in the last three weeks, I've evolved. And yeah. I mean, that's what you, I thought you didn't have to, well, I mean, the interface is because we don't have an SDK that has usability with Cloud Functions. But if we, if you personally like never had to work with any TypeScript features, like would you be willing to, I mean, I know you're making lots of compromises, but what would you be willing to be supportive of that that file, for example, or that feature within the repo? Well, I mean, yeah, I suppose, but like the truth is, like if I'm working on a repo, I would want to be able to like actually understand everything and work on it. And I think that's why to some degree I'm just saying, can we take it slow? Right? I like my fear, when I look at your PR, my fear is, oh my God, everything's going to be changed to .ts. And then I'm not going to have any ability to contribute to this. And because we don't already have rules in place to say it has to be pure JavaScript, well, then, you know, I can't control whether or not somebody is writing TypeScript because the linter doesn't pick that up. So let's go over the fears like one by one. So like, I mean, what, like if the PR included the linter that enforced just pure ES6, no TypeScript, like would that be welcome? Well, and that gets me back t