 Hey, John. How are you doing? I'm actually doing okay. Whether if you're in confiscated heat and up, so that's good and bad. Yes. Right. Hey, David. Hello, good morning. Morning. Ray, are you there? Yep. Good morning. Morning. Tommy. Hello. Morning, Ginger. Oh, good morning, Doug. Sorry. That's good. And Falco. Hi. Hello. Right. Hey, Lance. Afternoon, depending on where you are. Yeah, it's lunchtime. That's for sure. Hey, Doug. Hey, Mark. Let's see who else joined in here. How many are you there? Yes, I'm here. I'm close. Yes, I'm you. And Mike. Morning. Morning and Scott. And Timer. Hello, how are you? Hello. Good. And well. Thanks. Hello. Mattias. Mattias, are you there? Okay. I think I got everybody else. How's everybody doing today? Not sure yet. Alive. Yeah. Still alive? Alive and not sure yet. Okay. That's the most optimistic answers, but it's better than the opposite, I guess. Yeah. Yeah. Yeah. Mattias call needs to be on like Tuesday. Maybe Tuesday would be more positive. Maybe. But imagine the pressure then to actually get something done over the weekend. At least now you can kind of try to stretch it out during the week. Feel guilty about it, but stretch it out. Ryan, are you there? Yeah. Hello. Hello. Mattias or Mattias. You're there yet? You're there. Hello everybody. Hello. All right. Good morning. Good morning. Good morning. All right. Community time. Anything from the community. People like to bring up. Right. I'm not hearing anything. So. This is kind of funny. I can't remember if it was last week or during this week. We found out from. Oh, Vinay. You want to go on mute? Oh, I'm sorry. That's okay. I think I turned in the, in the, in the list now. Oh, Eric. I missed you. Good morning. Right. Three after let's get this show on the road. All right. I'm going to put that up in the, in the, in the list now, too. Um, I was going to say, oh yeah, so I got a message from Liz. Who's the TOC chair and apparently the TOC would actually prefer that we not become a working group under SIG after the right. They would actually prefer become our own SIG. And so they're trying to set up a special time for us to have a conversation to see if we can get the right scoping to make that happen. I don't know where it's going to go, but I just thought I'd let you guys know that that's the current status of things. Just kind of interesting. I mean, on the one hand, it's actually, it's kind of nice that they think that our area is important enough to warrant its own SIG, which I guess is good. But that also then probably means lots of extra bureaucracy for us. So good and bad points. Anyway, just how I'd mention that. All right. So technically, we do not have an SDK call scheduled for this week. However, given that people have done things like added SDK type topics to our agenda, there's a lot of chatter going around, around some relatively significant topics, at least my opinion, they're significant in the SDK Slack channel and issues. I'm wondering whether we should switch back to having it every week for a while. What do people think? In particular, the SDK folks. Not starting from this week? Oh, no, no, not this week. I think it's too soon. Yeah, that'd be unfair to people who missed out on this call. So starting next week, should we switch to every week for a little while? What do people think? The engagement. Say it again? I would be glad to have that regular engagement since, you know, there's a lot of activity. Yeah. Okay. And that way, people don't feel like they need to add SDK topics to this call because this call is typically not about SDK work other than just the status. But if we have extra time, then I'm okay to talk about it. So tell you what, if there's no objection, I will send out a note to that effect and we'll start that next week. Okay. I just don't want everybody to have to wait two weeks for some hot topics. All right. Update on the workflow stuff. Timmer, you want to mention what's going on there? What's going on is we do have a meeting just with the Argo team, I think Monday, the 11th. So we're going to start, I guess, our kind of hopefully talks with them about a possible integration and see how that goes. And yeah, that's it. We did have our monthly meeting and it went well and we're just checking on things. But yeah, so next step is to talk with the Argo team. And actually it's funny, I know it's not to this meeting, but I did have a question about the Java SDK deployment on Maven repositories, but they might not be part of this. Maybe later if there is time. Yeah, I was going to say, let's save that for later and if there is time. All right. Cool. Thank you. Any questions about the workflow stuff? All right. In that case, Clemens could not make the call today, apparently Microsoft gave them today and tomorrow off, lucky them. However, we did on last week's call talk about bringing up his proposal for a new subworking group. And this to be clear, this would be under the cloud events banner, not serverless. He wants a little subgroup here to work on this. I guess that's about it. I don't think we need to repeat everything they said there. Does anybody have any questions, comments, anything about this? Okay. Even though he's not on the call, oh, I'm sorry, Ryan, do you want to say I mean, I think this just needs to be answered. I agree with this and I think we should explore it as a subgroup, but scoping and how it relates to the discovery work is my big question. Okay. But it sounds like you think that's something that could be worked out once we go past the initial decision of yes, we're going to do something. Yeah, I think so. Okay. Cool. Okay. So any other questions or comments? Because if not, I'm going to ask if there's any disagreement to approving this as a subwork group. Okay. Not hearing any questions or comments. Let me formally ask the question. I just said more comment to the question that was asked, is that like, these are the kind of things that we tried to take on a discovery. So like, let's make sure that we join in with that work, like that it's not totally off to the side. Yeah. I have no, I can't speak for Clemens, but I can't imagine he would want it to be completely disjoint. Yeah. Okay. All right. In that case, let me formally ask the question. Is there any objection to approving this as a new subgroup under cloud events? All right. Not hearing anything. Thank you. Thank you, everybody. Clemens will be thrilled. All right. And so I'll work with Clemens offline to talk about the structure of how this works. For example, will we want to try to squeeze time into this call? Do we want to set up a separate call? A directory structure or repo structure, those kind of things, you know, process type stuff. We'll talk offline about that as necessary and we'll bring that back to the group before any decision is made. All right. Okay. Let's talk about issues in PR now and PRs now. Sorry, Doug. I have one more comment on that. Yes. Like we, it feels like we started the discovery subgroup or the discovery work as well as the subscription work and it feels like we haven't made like meaningful progress on like those as a whole. So I guess my other question is like, should we, should we make sure we focus on one thing and not, and not make, you know, slightly incremental progress on things, but not getting anything done? Yeah. It's funny you mentioned that because I actually did talk to Clemens slightly about this before when you first proposed this. I said, you know, I don't necessarily have a problem with this concept. I just fear that it's going to slow down the other work that we have going on. And he didn't seem to think it would obviously it's just his opinion though. I, I have a feeling this is not something that we can necessarily fix up front. I think we have to see how it plays out. And I think your initial comment there about things appearing to slow down on the two new specs is definitely true. And I've definitely been concerned about this, which is why I've been trying to open up issues here last, you know, today to try to force some discussions to happen and in particular then hopefully force some PRs to happen. I don't know whether it's because people are losing interest, people are just busy. I don't know what the reason is. I'm looking, I would love it if someone wanted to chime in and speak up in terms of what their thought process is and either why things seem to be only slow or ideas on how to speed things back up. I think this is a good topic though. So thank you, Ryan, for mentioning it. Sure. Anybody want to jump in? Yeah. And it's like I don't have a specific concern. It's more just an observation. Anything. Yep. You're not alone. Mark, did you want to jump in there? Nice. You came off mute. Well, you asked a specific question that wasn't relevant to my comment, but I'll just throw it out, which is that people should comment, make all of these comments into the proposal that what is it, issue 610? Yeah. So the comments can see your concerns. Yep. Definitely true too. Okay. Does anybody want to comment in general about the appearance of us slowing down on the new specs? Oh man, you guys are going to be picking on somebody at some point. I don't want to do that. Perhaps focusing seems like a good idea. Can you elaborate on what you mean by focusing? What was just recommended that we would choose one and focus on it for a bit so that our attentions aren't diverted or bisected? I think it would be reasonable to make a push to actually implement a reference of the discovery and subscription APS. That would help force issues. True. I mean, until somebody actually uses this, we may have created garbage. I'm going to take some notes here. Of course I can't type. Okay. Is anybody actually thinking about doing implementation? I think so. Is that something that you were thinking about doing relatively soon? Or is it just in the back of your mind? No, I mean, I mean, if we have a proposal for a spec, I think we should definitely have an implementation. I mean, a reference implementation, not something that should be maybe used as a, as a production-ready implementation, but at least something that people can look at when they will start implementing the spec. I mean, that makes sense for people. I think so. Also to be sure that the spec is implementable. No, yeah. I think that's true. I mean, we did something similar with cloud events, right? That's some of the reason behind the demos. That's some of the reason behind the SDK work, right? Is to force implementation and get real-world experience with it. So, Jim, your hands up. Yeah. I mean, I was just going to, my understanding of your original question was though, building an implementation to see if the spec makes sense. Rather, yeah, I agree there should be a reference implementation in the future, but I think the first step is to try and implement what people are designing, almost like a code. I don't want to say code first rather than spec first, but it seemed to be that sort of approach rather than coming at it from a reference implementation perspective. Maybe I misinterpreted. I suspect Mike's comments was just get some code out there, whether you want to call it reference implementation or just to prove a concept, just to prove the thing and actually work. Yeah. Maybe like what I did with the, with the graph QL, like I wasn't convinced that that was going to work. Yeah. So, Scott, your hands up. Yeah, I was just going to say that in the, the effort of developing the SDKs for the original cloud event spec, we found a lot of questions and holes in the spec that made the spec better. So if we're serious about the, these, these two new specs, we should definitely make a reference implementation. Yeah. At this point in time, is there anybody willing to raise their hand to say that they would be interested in it? At least in the short term. I know long-term, I'm sure people will probably come on board later, but I'm just wondering if some of that we can get started now on or is it too soon? People too busy. Interested in the implementation or in the spec? Well, I'm assuming, I'm assuming or hoping that everybody on this call is interested in the spec. I was thinking more about the implementation. Okay. So no one has time right now. That's interesting. I am definitely interested, but time is the, that's the problem, right? Time, time. Okay. I'm looking for ideas on how to try to address this issue. Right. Like I said, I tried to open up a whole bunch of issues today to try to force some discussion and stuff. I'm hoping that. Some of those discussions will pan out to more activity. Do, does anybody else have any other ideas? Because, because I'm stumped here, to be honest. I mean, unless we guys want to just give it a little more time and see, you know, whether the new issues help, whether someone will magically find time to start doing implementation work. Obviously we can't strong our people tend to doing stuff. This is like open source, right? But I think this comes back to the focus issue. Yeah. There seems to be a lot of, you know, I, you could even argue could split discovery and subscription. Yeah. Yeah. And maybe it's just the size of those, those things that are difficult for people to digest. If they're not. Intimately involved with it. If that makes sense. So, so if, if we as a group could say we'll do. Discovery, then we'll do subscription, then we'll do, you know, schema management or whatever. I think people might then be able to align around that. So. Okay. Just, just my thought process on that. In general, Jim, what you said makes sense. However. Given that I don't see any real activity on either specification. It's hard for me to claim that it's because people's time is split between two. Point taken. I would, I would, you know, say that I haven't really had the opportunity or, you know, to sit down and really sort of. Try and digest everything. So I'm from a personal perspective, I'm relying on these calls, which isn't, which isn't the right place. Obviously. So let me ask. Go ahead. Go ahead. Nice. Sorry. Ryan. Sorry. Yeah. What was one thing looking back, it felt like we made a lot of progress when we had. Actual working subgroups dedicated to these issues. And once we pulled them back up. You know, we merged those four requests and then the, the activities sort of died off. So I wonder. If just. You know. Not, not strong arming, but assigning responsibility. Would be helpful. Okay. I have a comment about that, but Lance, your hands up next. Yeah. I mean, I don't know. How much longer I can keep saying I'm, I'm new to the group and, and have that be an excuse for not do doing a whole lot. But that's part of it. You know, not, not being willing to, at least for my. Self, you know, just that data point. Not being confident to jump in really deep in lots of different things. So early in my tenure here. And then. Also. I'm just super busy. I think these are things, both the subscription and the discovery are things that I will down the road really care about and need to have, but I'm just not able to commit time to them right now because I'm building all the things that lead up to that. Yeah. Well, I noticed you haven't been shiny as the K work. So that's good. So, okay. Yeah, go ahead. Go ahead, Francisco. Yeah. Yeah. I've climates already. Something where. He wants to start from. I mean, there's already something, some ground to start this work, or it's, it's all from scratch. I'm sorry. You're asking about Clemens proposal, right? Yes. I do not know if they have a specification written up. We'd have to wait for him to come back to know. But I, to be honest, I'm not, I'm not as concerned about that right now. I'm more concerned about the slowness of our two specs in front of us. And. Ryan, your comment about things making progress when this, when we had subgroups, I, I, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, you know, an image of things making progress when when we had subgroups, I, I do agree with you. My, my concern with, with sort of punting it to a subgroup is it feels a little bit. And maybe I'm. I shouldn't be speaking for Mike and Clemens, but it seems a little bit unfair. Um, Because I, I felt like we basically had two people doing all the work. And I know that's not necessarily a hundred percent true because there And that doesn't seem quite right. We're supposed to be a group here trying to push this thing forward. But Mike, am I misinterpreting what I kind of saw? There's a reason I'm not volunteering to do another implementation. Yeah. Right. And like I said, I don't think it'd be fair to ask you, right? That's one of the reasons that you took this on to get the initial draft out there, but then it was supposed to be handed over to the rest of the group to work on. That way, winning would not be on your shoulders. Yeah. Yeah, I think that's fair. And I don't think some groups are the solution. It's just more just an observation that when we had folks dedicated to it, it did make progress. So yeah. And to be honest, that's part of the reason why I was opening up some issues because if someone saw a small issue out there, they may then jump up and say, Hey, I will take that small issue. My serve example, Lance was saying he's new. He's maybe a little uncomfortable trying to jump in there, but maybe one of those issues is small enough. He can say, I'll take a stab at some new wording for that, right? And that way we have concrete owners and I can nag that particular person. And it gives you that that that that feel of a small dedicated work group just on an issue by issue basis as opposed to on a spec basis. So I'm not hearing any any real significant suggestion here in terms of how to fix this problem. So I'm inclined to say. Keep on the path or on right now and ask people to please open up issues. Even for things that you think are silly, just to force some discussions because, like I said, in another call, I actually think that's what happened with cloud events. We had a whole bunch of issues out there. Some of them were, in my opinion, really silly in nature and just flat out wrong. But in nothing else, it forced a discussion because we need to get rid of the backlog of issues. And that forced us to have a discussion about that particular topic, even if it was to reject the idea. And that got some discussions going and it made people think about other things to change the spec. So I guess at this point, all I could do is ask for people to please take some kind of action. It doesn't have to be a full-fledged PR. It could just be, hey, how is this thing going to be handled and open an issue? Does that seem OK? I mean, I don't I don't know what to do. David, do you want to say something that that thing is reasonable? It's from from our perspective, in terms of where I'm at currently, in terms of my internal group, we've had some recent product changes that slowed a lot of things down. So I'm trying to reevaluate what this project is doing with some other projects are going on separate. But I'm trying to see if there's actually connection. And that's with open telemetry. So I'm going to be taking more time looking at the spec and looking at the issues. It's just going to take me a little bit more time to get caught up again because I've been out of touch for a little while. OK, all right. Well, until someone has a concrete action, well, thing for us to take with the proposal for it, I feel like we're kind of stuck in this. See how it plays out mode. So OK, let's move on to something a little more concrete and possibly actionable. If my computer wakes up. Come on. Can you guys see the spinning thing? There we go. All right. I was hoping this would be an easy one to get behind us. So Fabio opened up PR to change the avarose schema. I believe this is their schema, right? Just to rename it for cloud events to Avro cloud events. It seemed like a no-brainer to me, but I know nothing about Avro. So I don't know what their schema docs are normally like. Does anybody on the call have any comment about whether this is a bad thing to do or a non-normal thing to do? It's so long since I looked at Avro. I think this looks non-backwards compatible, isn't it? Changing the names of things. Right. And my comment would be similar to that. But also, if it's already Avro, putting Avro cloud event seems like a bit redundant. OK. I just had an opinion, again, without knowing too much context. So I just want to throw it out there. OK, Vinay, were you going to say something? Yeah, can I make a comment? Also, it seems like we're not necessarily changing the field name. It's just the, and I don't understand the implication of it, but it kind of at the outset seems a little benign, but I don't know about backwards compatibility. Yeah, that's the one I was going to ask about. These fields that are changed, are they simply descriptive things or are they actual like a scheme of things that's going to break running code? Exactly. Well said. If your code relied on that name, then regardless of whether it's a scripture or not, it will break it. Right, but does, would this word right here appear like on the wire? I don't know. Does anybody know? Well, I would imagine it would, right? I mean, it could be Marshall. I don't know. I don't know what that feels like. I don't know anything about Avro, that's what I'm asking. I believe, I believe Avro doesn't allow you to rename fields in a backward compatible way, but I would go double check the documentation. OK. Well, it sounds like there's enough possibility of this being a breaking change that I'll take the action item to Pinkfopio and ask him about that, since I'm assuming he's an Avro expert. And if he comes back and says, yes, it's a breaking change, then we need to really think hard about whether we want to do it, because that's not good to put it that way. There is a similar breaking change with changing the namespace in another issue. No. Always in the Avro schema. I saw that today in the Puerto Rico ads. In, hold on. Yeah. This one? 613, yeah. I mean, this one tries to change the one where you ping me. This one tries to change namespace. I have no idea how Avro works. To me, it looks correct. But other than that. OK. Well, this one was a work in progress. That's why I didn't put on the agenda. Of course. But I mean, we need to make sure this is not a breaking change, too. Yeah. OK. Thank you. Thank you for mentioning that. I'll ask on both those issues then. Thank you. Where was I? OK. What was the other one that was 615? OK. Can do. Thank you, everybody. All right. Let's see about this issue or PR. OK. So apparently this having null here breaks. I could think tooling is what this is Thomas, right? Yeah. Thomas was saying this will break some tooling. And so he just wants to remove it. I'm assuming no one cares. This is all part of the new spec. And everything's going to change anyway over time. But anybody have any problem with this? OK. Once he signs his commit, we will get that one merged. If there's no objection, I'll fix that. All right. Distributed tracing. Francesco, do you want to talk about this one today? Or do you want to actually or do you or because there was activity recently, or do you want to continue having these discussions offline or do you want to try to force a discussion today on the call? I feel there is there isn't something else to talk about. OK. I mean, Ian is not there, I think. I don't see him now. But I mean, he's proposing to change the behavior of the spec. While my PR is not changing the behavior, it's just trying to reward and make clear what's the goal of the extension. Right. And I feel like, well, I said this in my comment yesterday. I feel like if he wants to make the kind of change that he really wants, which I think is to make more of a full-fledged tracing kind of spec within the cloud of in space, I think that warrants a separate discussion and separate proposal. Agreed. So what I'd like to do is ask for the people on the call right now. Given the current set of changes here, I think for the most part you haven't really changed anything over the last couple of weeks, right? I think I had a minor sync tech thing last night, but that's minor. Yes. OK. What do people think on the call right now? Does anybody have any concern with merging this? Does anybody think it goes backwards in terms of clarity? Because we're not looking for perfection here. This is just a proposed extension. We're just looking for whether it moves the ball forward. Make it better than it was before. So no one seemed to think it's a horrible move. I mean, formally then, is there any objection then to approving this modulo the syntax errors that I noticed last night? I already noticed that. There you go. OK, never mind. I didn't notice that. OK, we're going to merge it then. Let's say somebody speaks up real quick. OK, thank you, everybody. Whoops. All right. What about the next one, multi-part? Do you want to hold off till Clemens comes back or do you want to have a discussion now? Let's hold off because, again, I didn't have time for this. OK, that's fine, guys. I know he has some opinions on this one. OK, so this one, I apologize. Probably should have removed this one because we talked about this one last week. So I don't think there's anything new there to talk about. I apologize. I should have cleaned that up. GraphQL. Mike, do you want to talk about this one today or would you like to hold off? I don't have anything prepared to talk about. I mean, well, it looks like to talk about. OK, well, it seems to me that at some point we need to come to a decision. And I know that there was, OK. I know that there are plenty of people who say that GraphQL is nice and they like it. However, I think the last time we talked about this, and this is, I think I'm probably very biased. So please, someone jump in and correct me. But my general take of it, most of the conversations we had up to date were, yes, GraphQL is nice, but we should probably still support a simplified REST API that does not require something like GraphQL. But we can do a GraphQL as an optional layer on top of it. That's my interpretation anyway of what previous conversations were like, but like I said, I'm probably very, very biased. Does anybody want to chime in? No, I mean that seems to be the sentiment. I would not be in favor of supporting two versions of the API. We will get drift and we will get incompatibilities and people will be unhappy. OK, I don't think we can necessarily resolve this on the call today if we do to make the decision, but I'm curious, does anybody on the call think that we should only support GraphQL? OK, Jim, you had your hand up there for a minute. Do you want to chime in? No, I'm a fan of GraphQL. I mean, I wonder, I understand a concern with drift, of resource or entity models or whatever you want to call them. But I wonder if you can address that with having common representations that are managed together. So that's certainly something we're starting to do, have common models that are updated together. I like the idea of GraphQL as an endpoint because I think it's gaining such traction these days. It's not like it's a new technology anymore. So yeah, I would say we should have both. OK, anybody else want to chime in? I think this is revisiting this topic and it is my only concern is from what reading I have done, it seems a more efficient manner to access data, et cetera, but it's the interoperability and being using REST for, I don't know, let's say a decade or so and how the implications are interoperability. That's my only concern. OK, thank you. Ryan, your hand's up. Yeah, I think I've provided this feedback before, but to me, success for this whole thing is adoption. And so I just question how widely supported and adopted is GraphQL across vendors, across companies, across systems. And that's really the question for me. It's like I like GraphQL myself, but is it something that's going to help or hinder adoption? Thank you. Anybody else want to chime in? OK, I think, oh, where's my cursor go? Yeah, sorry, go ahead. So just my two cents, I just wanted to mention that GraphQL is pretty dumb specification, actually, if not talking about the HTTP binding and so on and so forth. And adding support for it doesn't require a complex SDK or anything. So I guess we are talking about very lightweight specification that's very easy to add support of. And there's nothing to be afraid of, kind of. Yeah, I am definitely hearing that consistent theme, that it is relatively lightweight, and it's not a huge burden. Forgive me for trying to put words in people's mouths. I think what we're hearing, though, is it is more of a burden than, say, just vanilla rest is what I'm hearing. And there's a concern that people have expressed that if we're looking for as wide adoptability as we can, rest might be the more appropriate choice. But, Jim? All that happens is a burden gets moved around. Yeah, because with the sort of query semantics, that's where if you're trying to do queries on a rest for interface, that can become very messy. And just GraphQL simplifies that aspect of it. But then it pushes the complexity into the server. But you're going to have that complexity for trying to decode restful-based queries as well. So I see them as complementary. But I agree there's a danger of sort of creating two solutions to the same space. And again, I think we come back to that until you have clients that want to integrate against these things and see what the use cases are. That's when it may become more obvious, which is a more viable option. Having implemented the GraphQL one, I found the tooling support for implementing GraphQL servers is in just about every language you could want. Super easy to use. I went from knowing nothing about GraphQL to having it fully working in the end in about four hours. It's not a big burden. So I would agree. I think it all comes down to the information model that you're trying to query on this now. I mean, is that part of the sticking point with this is just trying to agree the model that we're trying to query on whether it's a GraphQL model or a restful implementation? I mean, the data, I think, is clearly like lends itself to a graph model. I also contorted rest to make it convey the same information. So OK. So to me, the most interesting bit of information that I have running through my head right now is when I asked if anybody thinks we should only support GraphQL, no one spoke up. And that to me says that we don't necessarily have to make a final decision right now, but we need to make at least a short-term decision on how to move forward. And it seems to me that the question before the group or the proposal before the group would be, for right now, design a restful API to get something going up and running as quickly as possible, and then revisit this issue again at some later point in time to see if, now that we have an experience with the rest API, is it too complicated? And would a GraphQL be easier? Or is it simple enough and that's fine? Or do we want the GraphQL to be an additional layer on top of it? We don't have to make the decision right now, but we have to move forward with what is the preferred or premier API that we're going to expose. And the fact that no one said GraphQL should be the only one should be support, I think the proposal then has to start with rest and then revisit this later. Am I being too biased here? If I had to pick one, I would probably pick GraphQL as the only implementation, but I don't think that's going to be a winning argument given the status of the group right now. So I guess the reason I didn't speak up is I know when to not fight a minority position. Yeah, I was wondering why you didn't speak up, but I agree with you. I probably would have kept quiet as well, because I heard enough people say or express concern that, yeah. Okay, so let me make it a little more formal. So I guess the proposal is to start out with the rest API and then revisit this issue at some point in the future. We can change our mind, but we would definitely revisit it before the spec goes 1.0, because before anything with 1.0, we can change anything and everything, including dropping rest if we wanted. Jim, your hands up. I would hate to abandon this. If that's the subtext here, I know. No. So I think we should keep this alive. And I would hope we can at some point get to a model where the endpoint can support both and just make it a choice for the client. Yeah, to be clear, I'm not proposing that we close this issue. I'm just proposing that we defer it, because I do want to revisit it again before we go 1.0. I'm just trying to look for, as we start hopefully filling out these specifications, what is the API that we're gonna write up tomorrow? Is it rest or is it GraphQL? And I think I'm hearing more people say, let's start with rest. So the proposal is to do that and then revisit this later before we go 1.0. Any objections or concerns with that proposal? Okay. No. I'm sorry, no, okay. There's no, yeah, no. Okay, sorry. Okay, cool. All right, now I did open up some issues that I thought might be worthy of discussion, but not today because I just opened them this morning. So before we jump into this SDK topic, are there any other topics related to the spec work, of any specs that people want to bring up? Okay, since this is an SDK topic and people may drop off and feel free to do so if you want to. Well, let me quickly just catch some people for roll call in case they do drop off. So drag over you there. Should I go over you there? Yeah, I was here. Okay, cool. Mattias, you there? Mattias, you there? I'm here. I'm here. Okay. This echo would nick me there. Echo would nick me there. Yes, I'm here. All right, thank you. Oh, well, I heard Doug, are you there? The other Doug? Yeah, I'm here. All right, Grant, are you there? Yes, I'm here. Okay, and which grant is this? We actually have more than one grant that has shown up. Oh, this is Grant Timmerman. Okay, got it. Thank you. And Jim, I got anybody else I miss? All right, in that case, thank you, everybody. Let's jump back to the SDK side. So I can't remember who added this. I apologize. All right, sorry, I added this. Okay, Grant, do you want to leave the discussion then? Yeah, sure. I do realize this could probably be in the SDK, but I hope it's fine here. So over the last, I guess year and a half, I've been, well, basically last year, I've been trying to work with the JavaScript SDK for Cloud Events. As at Google, we use Cloud Events for Google Cloud Functions. And we basically have our own, we use TypeScript, Ref, many Google open source projects. And the current SDK for JavaScript does not support TypeScript. And it also uses a really weird object creation pattern that's sort of Java-like. That's not very JavaScript-y. And in order to support TypeScript, the library would be used to be converted to TypeScript. And you can't just add TypeScript support on top of JavaScript. However, there's been some friction and, I guess, resistance to add TypeScript support with the current, well, with at least one maintainer of the library. And so I don't really understand how to proceed from here. Yes, there's two options that I listed right there, whether we could say we should add TypeScript support to the JavaScript SDK. This requires you can use the JavaScript files to TypeScript files, adding a build, walk command. You don't really have to change any of the actual source files. Another option would be to create a separate TypeScript repo. Although in the end of the day, it's all just JavaScript. And you'd have to publish a separate MPM module. I was speaking to Lance about this. He said he'd be fine with going with the most popular option of the group. So I don't know if we should do it here, but I was looking to get a vote for either option one or option two. What do you think, Doug, or anybody? Well, since I'm the one who is causing all the friction by pushing back against this proposal, I'll say a few things. I think that there's a third option, which is adding TypeScript bindings to the JavaScript, so that we don't have to rewrite things in TypeScript or create a separate repository. And in the issue that's linked here, I hope that I was pretty clear about that. Like, I'm not opposed to that. But when I think about what it means to, like what would be the motivation to change over to TypeScript as a whole, like completely? That's a developer productivity thing. The end user doesn't really have any knowledge of this for the most part. I will not be productive in TypeScript, so I'm opposed to it. That's really it. I don't know that there's much more to say about it. I'm not opposed to having TypeScript bindings and having those bindings published either under definitely typed or maintaining them within the repository. I'm just opposed to switching everything over to TypeScript. Okay. Anybody else want to chime in? Since we were having similar issues in another SDK, Java SDK, I wanted to ask a question. How does it work in the cloud events SDK community or group when there's one maintainer for library and then there is controversial discussion and decision has to be made. So far, I've seen that the maintainer decides and it doesn't feel that the SDK is community driven. It's rather one person who makes the decisions, but then it doesn't really sound like a CNCF project then. Okay, that's a slightly different topic. Okay, sorry. Well, no, I did, well. Let me, I'm sorry to interrupt you. You go ahead. Jump sort of not necessarily second to what Sergei said, but rather point out to the fact that it is my strong belief, like I don't know much about JavaScript, right? But there's somebody who does and somebody who believes he may be more productive or somebody who believes that it will really help the community to be better. So that in and of itself says we need to do it. It's not a question of if it's a question of how do we gonna approach it? And right now, for example, within the given two options, it appears to me that, for example, option two is better because it doesn't make you, doesn't put you in a position to make a binary decision, right? But again, to Sergei's point, it's really more about the fact that there's a community and community expresses certain desires, certain concerns and the maintainer of the repository may not be aware of all these concerns. And that's why we have this meeting, that's why we have this feedback that you're asking us about and so on and so forth. So we need to, I guess, listen, learn how to listen to it in a way where it's not the question of whether we need to put TypeScript support or not. It's a question of is it requested enough? Is it like something that is a typical JavaScript developer would want, would ask for? Then let's figure out the way how to do it, not whether we have to do it or not. I mean, that's just how I look at it. Okay, well, thank you. Scott, your hand's up. All right, yeah, I just wanted to say plus one on potentially a new repo for TypeScript because it does seem like a different language and it is a different productivity. So personally, I hesitate to use TypeScript but I would use JavaScript, but I also don't really want to block the TypeScript people from adoption. So for me, it makes sense to have to, even though it compiles down to JavaScript. Oh, sorry, is that on your hand's up? Yeah, I guess, let me, I don't have a personal opinion about TypeScript or some TypeScript because I could be both irritating. My question is for the people who are living this, there's the implementer side and the consumer side. So if we take this, hey, it's a big world like multiple implementations run and all of that, what confusion is that gonna cause from the user side where they come in and say, okay, there's two equally supported SDKs for nominally the same set, the JavaScript browser ecosystem. What is that gonna do? Is that we just let the market decide or is it, what are we saying about that, good or bad and how is that going to make the consumer's life easier or harder? Thank you, John. Lance, I think your hand's up next. Actually, I was just a minute, Lance, Scott, is your hand up or is that old? I'm sorry, it's old. Okay, that's what I thought, just wanna make sure. Lance? So I wanna be clear, it is, I don't think it is a binary decision because you can basically, you can create TypeScript types that can be published to definitely typed or within our repository that will expose your JavaScript code through some TypeScript representation. But you don't have to write all of the code in TypeScript, you just write these little types that expose that. On other projects that I've worked on, this has been the way that we've handled this. And I would be totally happy with that. I just don't wanna have to start writing TypeScript. And I don't see, if the end user experience is still just NPM install and they're not actually working with the code itself, then it's the committers, the maintainers, the developers on the SDK who this primarily benefits. And, you know, I get it, but, and I said in the issue that I would stop contributing to the repository if it were converted to TypeScript and I didn't mean that as a threat, I just mean it that like I don't write TypeScript, that's not what I do. And so I won't contribute to it. So I think Lance, you were the one that added option three down here, right? Yeah, that was me. That's what I was saying about, you know, that, you know, adding TypeScript types to the repository. So I'm gonna ask this question, not having touched Java in years and never touching TypeScript, is option three viable? Can you add this stuff to the existing repo without reinforcing someone to step over to TypeScript, meaning they can still do JavaScript if they want or they can use TypeScript? Or does it actually require a separate repo to make it happen? No, it does not require a separate repo. It's, I mean, I can give you, I'll link an example here in a sec. It's a conversation. The thing is, we tried this option before and we literally like the TypeScript findings got out of sync and they were unusable. And so then we deleted them. It's not something that modern, it used to be more common, but not the way that you can really write findings anymore. That's a fair point. I mean, like I said, I don't really do TypeScript. So... So then what's wrong with option two? I mean, let's just, it's a concrete option proposed by Grant, right? Yeah. So... I mean, so from my perspective, like we have these Google modules that use Cloud Events, but we cannot use the Cloud Events SDK because it's, I mean, although it's an MTM module, and there's very other issues of using like a doger pattern, we don't have any type definition or any guarantees of the code before execution. And that's unacceptable for like, if you're publishing a new module, that's the point to knowing the users. So we really have an internal version of a Cloud Events SDK and that serves a shame because you can't contribute to the existing one or because it doesn't support TypeScript. Now, I wouldn't be opposed to creating a separate repo, which is something that I think will probably be the best option here. I think it'll still be a shame that we're gonna have duplicated functionality of the node repo. Well, that's what I was gonna ask about because obviously option two is, it sounds like it may be the best option based on what you guys are saying. However, I do know that we've had some trouble in the past with getting people to participate in these SDKs because they get pulled off on other things, you know, they're busy and stuff. And I'm wondering now whether having two repos that are so similar in nature is just gonna make that problem, you know, worse. Well, I mean, or once there's a workable TypeScript SDK, I'm gonna sort of integrate that into at least one module which is used with serverless, like Google. And so it'll definitely be used and maintained. So let me ask the question, it's almost out of time here. If we were to choose option two, in other words, create a separate repo for TypeScript, is there anybody on the call who'd object or thinks that is a bad idea? To go back to what you said earlier, it's not just, there should be no objection. It's like you said, let's try it and then before the two O there's gonna be chance to revisit it, talk about it again and either drop it or continue with it. So that's how I would look at it. Yeah. So it's definitely yes for me. Okay. Anybody else wanna say good? I'll just say, I think option two sounds like a good idea. And at a later point, there could be a merge that's really necessary. Yeah. Okay. It's like a spin-off. I mean, you let it run independently and then when it gets to a certain level of maturity, you figure out whether you wanna acquire it or, you know. No, I totally agree. I'm just trying to follow some process here. So, okay, so tell you what, let me do two things here. One is I'm not hearing any objection from it. I will go ahead and create the repo for you guys. That way you're not blocked. However, from a pure process perspective, I do think we have to go back to the full working group and make sure no one broadly has any problems with that. I can't imagine they're going to but just from a process perspective, I wanna make sure that we're not treating this one any special. So what I'll do is I'll add to next week agenda the idea of making sure there was no objection to creating the repo. And if for some reason somebody raises a good point and everybody says, hey, this is a bad idea and we voted down, then we'll kill the repo. But at least in the, I don't think that's gonna happen. But at least for the next week or so, you're not blocked and you can still make forward progress and I'll create the repo today. Does that sound fair? Don't get me. Okay. Anybody have any concern with that process? Okay. Cool. Excellent. In that case, any, well, I guess we're taking over time. Did I miss anybody for the agenda or for the attendee list? Just wanna make sure no one else joined. All right, cool. Thank you guys very much. And remember, we will be tapping the SDK call next week and it's gonna be a weekly meeting from now on for the short-term anyway. All right, thank you everybody. Have a good week. Have a good week. Thanks, Doug. Thanks, Doug. Thank you. Thank you. Bye. Bye.