 Let me do one quick blast pass then we'll get started since it's three after the hour. Oh Doug, are you there? Yes, I'm here. Excellent. Thank you All right, how to go ahead and get started. We have a fairly full agenda today Let's see action items. I don't think there's anything too exciting there to nag anybody on oh other than Austin Were you gonna set up another SDK call or we're gonna play that by ear. I could not remember what you decided We are gonna set up another one because we have to work through some versioning issues The only thing I'm kind of waiting on is I think our team is actually gonna submit a first pass at the JavaScript SDK Shortly here, and I just want to see what learnings we get as a result of that before jumping on the next call Okay, I think we'll be in a more informed position. So hopefully we'll have that done in about a week And then we'll set up the next SDK call and again anyone who wants to contribute to the cloud events SDKs There's a design documents and Doug has Doug has created repositories on the cloud events GitHub org to which you could submit BRs Yeah, actually since you've kind of jumped into the SDK discussion. Let's do that right now. I Did create the GitHub repositories as you said except for the goal line one that's actually gonna get transferred over from VMware and they're still working on the The legal process or what do you want to call it to get it transferred over? However, I have yet been given the GitHub IDs of people who want to be made Maintainers or admins that are you want to call it on those repos? So I still need people to send me a note or ping me through Slack Tell me who they want added as admins because right now no one can do anything with PRs except for me or the admin Or the other admins of the group. So I just need some GitHub IDs if you guys want to send those to me Okay, I've got a couple coming your way right now Doug. Excellent. Thank you Just to finish that out. Is there any other things you want to say or any questions for Austin on the SDK work? Okay, so let's jump back to the normal timeline then the agenda Community time is there anybody on the call who's not a regular participant from the broader community who would like to bring up an issue for discussion? All right, not hearing any whoops. Sorry wrong screen scroll. All right. Kathy. Is there anything you'd like to bring up relative to the workflow subgroup? And no, not really. No, okay. Thank you much. All right next the interop demo So I did send out a notes to people talking about the results of our Meeting that we had last week talk about ideas around the next interop event There was a document out there linked in the agenda right here Right now you seem to be heading towards some two different possible applications one involves Human language translation. So for example an English sentence might get passed through a bunch of different nodes And each one's translates to a different language Then by the time it comes full circle is transit back to English and we get to see how our systems butchered it as they went for one language to another The other option is to do sort of a mad libs kind of thing where there's a sentence with gaps in it Where where we say okay a verb goes here and now goes here an adjective goes here And then each node that's participating in the demo Fills in part of the sentence and we get to see you know, what kind of funny sentence it produces In order to do either one of those we kind of need to know a couple of things I should also mention we talked about Potentially also leveraging different transports between the various nodes just to sort of show some interoperability around that as well But in order to decide which way to go on these things I think the biggest decision point here is actually things like What are the transports? Can people actually support in time for say coupon Seattle? which companies can support things like in English translation or just Language translation those kind of things because obviously if we only have one company that can do one particular transport You're not going to get much of interoperability statement there Right, so what I really need from you guys is to fill out in this doc these two questions What transports can you support in time and do you support language translation? Those will help us decide what the demo is going to look like So please when you get a chance Let us know what your company can actually support and that'll help us make a better decision because you want to Make it as inclusive as possible So for example, if no one except for three people support language translation We may not go that path right they have to do a mad libs kind of a thing Which I think is something that everybody probably could support relatively easily It's just randomly picking a word from a list But anyway, think about that please fill in with your company's abilities And the time frame we're looking at is probably Kubecon Seattle, so that's November December where I came out exactly one later in the year Any questions about that are comments? Okay. Oh go ahead. I have a quick question, Doug Can we submit we could probably still go submit our own individual talks? to Kubecon right and if because our company has serverless framework version 2 coming out of which cloud events is kind of a premier concept and We've got some really cool interoperability stuff to show off, but I think it's best if we probably just go submit our own Our own talk for that Is this Well, I guess that's just standard process right we can go submit separate talks for this too. Oh, yeah I'm going yes. My only hesitation there is I believe the deadline for submitting talks is beyond us Okay Looking at the website and at least that looks kind of done They didn't know what decided last week. So yeah, yeah So do we have a reserve slot so we will have an intro and a deep dive session Yes, so if for example, well, so let's take example the Gosh, where was it the Europe one? I can't know what city we were in where you did the demo Austin if someone wants to do that interrupt demo as part of a talk that they had accepted I think that's great If that does not happen then we can leverage our intro and or deep dive sessions to show the interrupt demo So we do have a we do have a backup plan if it doesn't fit as part of someone's normal presentation that they want to share with the rest of the group That makes sense Yeah, yeah Okay Any other questions or comments? All right next is Okay, Shanghai. So I'm trying to remember now, I don't think we had a phone call yet We do have one I believe right after this phone call today To talk about in essence this list of topics that people put down for potential discussion points at the intro and face-to-face for our work group or I guess work group in Shanghai If you're interested in participating in this discussion It will be I think on this zoom call right after this one You feel free to join even if you're not going to be there But we're going to be talking about what topics to discuss Who's going to volunteer for talking about each topic? You know to do the presentation We only have 35 minutes per in per session meaning 35 for the intro 35 for the deep dive. So we don't have a whole lot of time But we're going to be talking about that on the call right after this one So if you have any if you want to participate, please join other than that any questions or comments about this Okay, just want to make you guys aware of what's going on there in case you want to participate Next let's see if we can get through some easy PRs first before we jump into some really deep ones. So well on last week's call Kathy had a pr with a relatively minor change but based upon a Either a miscommunication or I just misread or something like that I thought that there may have been a possibility that other people may have misinterpreted Kathy's intent because the subject of her pr actually didn't say a whole lot other than she was just trying to make a change And so I think other people may have done what I did is a misinterpreted where she was going with it So she and I did a little bit talking and we came back with some slight changes And I wanted to make sure you guys are okay with it since this is a change of the governance stock and that's kind of a Touchy subject sometimes and I didn't want to To approve anything without you guys getting another chance to see it Um, so there were two changes that Kathy and I talked about first was to add the phrase in aggregate to make it Try to make it clear that When we take attendance, it's either the primary or alternate person can be there for three out of the four meetings it So it's if either one of them is there for example today Then that company gets credited for being there. It that's the first one the second one was Kathy wanted to make sure that she could basically change who the primary and alternate people are But we want to make sure that we don't necessarily Encourage game playing by having for example, some company have a different person every single week Just to get their voting rights. That's feels Not quite ethical So we decided okay fine You can change it obviously because people move in and out or maybe they're on vacation for a while but we wanted to limit it to No more than once per month making those kind of changes and to be honest Uh, our history has been this thing's rarely changed at all So once a month seemed to be you know, something that was a nice middle ground position there I have a question I don't understand the point of view that it's gaining the system to change every week like if you really want to go to the work of Fighting a new person to attend every week. Is that really bad? So So this is kind of my personal experience in other organizations like this where I have seen companies Do exactly that they get people to show up for no reason other than To get onto the agenda aren't sorry to get on the attendee list So they can have voting rights just in case a vote comes up But other than that they pretty much do not participate in the working group at all And I grant that this doesn't stop any of that because you could still play some games But I I wanted to make it clear that if someone comes up to me and says every single week Hey, Doug, we want to change our alternate and primary and every single week this happens I felt like I needed some way to push back and say guys Something's weird. What's going on here? This isn't this isn't the intent of what we're trying to do here of Of having you guys change out a different person every single week because it doesn't make it look like you're interested And I needed some way to sort of push back on that kind of behavior. That's all I was looking for Okay And like I said, this hasn't been an issue because the list of really changes And most of you guys are Are I think barely active and and doing the right thing. So I don't I don't think it's an issue This is just a safety valve for me All right, any other questions or comments? All right, any oh, I'm sorry Kathy. I should I did you want to say more about this Kathy? I apologize. I sort of dominated that one No, I'm fine. I think the The whole point of you know, um Sometimes need to change it because the primary or alternate You know business trip together. So Yeah, okay All right. Thank you Yeah, Doug. Yeah, it's a little pedantic But the the verb done there seems a little off like maybe and can be changed by notifying or changes are Changes are done by notifying Can be okay. Um, yeah So it can can be changed would be fine. Okay, hold on a minute. So you want Done can be changed. I assume everybody's okay with that minor working change, right? Okay, it says yeah, it says can be done. It can be can be changed. Okay. I can make that change. That's easy enough All right, any other questions or comments on this one All right any objection into adopting it with a slight wording tweak that jesse proposed All right. Thank you guys very much Okay, this one was raised by me Basically, I was going through our roadmap just trying to see where we were And I realized that there was nothing on our actual roadmap doc That gave somebody new to the group an indication of how far along we are in roadmap So pretty much I just wanted to add something that said oh, by the way, these two are completed And here's the dates that I think we completed them This one was easy because we actually have a formal release for it. This day was a little bit fuzzier for me So I kind of guessed based upon when we added the license doc and I thought we kind of completed them I don't think the dates on this setup matter too much But it's fine to get in the pattern of actually saying we actually completed these things going forward So someone looking at our group can see where we are on our timeline Hopefully this isn't controversial Any questions or comments on this Any objection to adopting? All right. Thank you guys Next one This one it was in response to issue 268 where I can't remember the gentleman who raised it But he basically wanted a slightly different layout for the list of specs or list of documents we have But I think in the before this pr This was just a flat list in a table form But it was a flat list And it we he didn't really think it was clear Which specs were sort of required or core versus optional and so that's what I try to do here I try to make it clear that there's a core spec, which is the cloud event spec And then you had a list of optional specs, which are the transports And then we have additional documentation things like the primer and extensions And just basically trying to find a little bit of organization around that Nothing semantic or nothing Normative change or at all. It's strictly some tactical Any questions on this Any concerns with hey in this direction All right, any objections or approving then Looks good. All right. Thank you guys very much. Those are relatively easy. All right So we I was actually trying to go through our backlog of issues trying to see where we were Trying to basically just clean them up And I identified five different issues that I was hoping we could go through relatively quickly to close out If we end up starting to deep dive on one of these I'd like to defer that discussion for a later time and we can just skip that issue But I'm hoping that some of these we can just close out really really quickly Um, hopefully most of you guys have looked at this because I did send out a note about it And I haven't seen any comments on these issues. They're saying that they think they should be kept open So the first one is you know, what open inventing is not or what is you know, what cloud events is not now um We now have a non goals section in our primer and I thought that that was a good enough first step Obviously people can add Additional prs later to enhance that But I thought that was a good enough to feel like we've actually addressed this issue as a starting point Any buddy have a different opinion on that one? Okay, is there then any objection to closing this issue saying it's been resolved? Okay. Thank you guys Sorry, let me do it this way Close with no action. Okay. Thank you Uh correlation ID Um, actually this one the next one go hand in hand. There's correlation ID and then there's causation ID These are in my opinion go hand in hand because they're both talking about adding additional properties related to obviously correlation type stuff Um based up on our previous discussions I feel like we've pretty much decided that we're not going to add any formal properties to our spec At least not at this time and that people will Through extensions add their own correlation type of properties To this to their to their message flows And so as a result, I felt like we could probably close these two's issues as As you know, we're going to resolve it through extensions Any questions or comments on that? Any objection to closing with no action then I need to You guys are going on. You're being too friendly today. This is great. Thank you All right log level attribute So this one actually would be really easy There was issue 63 Which actually was the pr for this issue And that one was basically trying to add a log level attribute And we decided to To close this in favor of the tracing extension which I believe Thomas added for us So all I wanted to do now was just to close this issue that was related to the pr This should be a no-brainer, but I didn't want to overstep my boundaries in case someone thought I was missing something Do we want to reference into the other pr? From that one, uh, that would be good. Okay. I can do that Um Oops To they just leave people down the right path. Yep. Yep to issue. Okay. I can do that. Thank you Uh, if I do that is there then any objection to closing this with no action? Okay. Thank you guys and Austin you opened up an issue a long time ago to improve our logo which I believe is done So I just wanted to verify with you or anybody else that we could close the issue That was associated with our logo improvements for now, I I think we we have something and Unless someone wants to propose a new logo if we could certainly we could certainly close this All right, any objection then to closing this one All right, and as a side note, I actually did get the stickers. So I will be bringing those to kuban shanghai And seattle and actually for those of you who might actually be in switzerland next week for the seattle summit I will try to remember to bring some there if you Find me. I'll I'll hand out some of those to you guys So that's all good news All right now to some more interesting issues Open messaging pr You guys have been awfully silent on this and I have no idea how to interpret the silence So let me just open this up for what What are you guys thinking on this one? Um, so I just po I just pasted a Blame link for the open message of specification for a particular line which Literally lifts text from our spec Which kind of suggests to me that um the open messaging spec is kind of feeding of some of the work that we're doing Um, this this is before if you recognize this is before my any change that I just did uh that we accepted I think last week, but this is the literal the same text um and which already says that there's a bunch of overlap between what we do and um What open messaging tries to achieve and if open messaging wants to be a similar type of abstraction Uh for messaging is what we do for eventing then that's fine, but then that kind of excludes precludes that we Have some integration and if things are at the same level of abstraction and appears that they are Um, then mapping makes very little sense Okay, so it sounds like in summary you're Against adopting this Um, I am mainly for technical reasons as opposed to it doesn't meet the bar type of thing. Yeah, I think I think from a technical perspective and first of all the the the the mapping that we have is I'm not sure what it says really um, because it seems to be mapping to this to this abstract model and so it's a It's a mapping between an abstract model and an abstract model and that seems very strange to me and there's Very little you can really do with that spec and and again if this wants to do messaging That's fine, but I don't think there's a there's a there's a way to make those things match Okay, anybody else have any comments What do people think about cleman's point of view? Do they agree or disagree or do you guys disagree or agree with it? You guys can't be so quiet. Come on Intimidated We need some input here because like I said last time around I feel bad that this guy's pr has been out there for so long Um, granted we went, you know, we had to define that bar and stuff But we we really need to give him some feedback about how we feel about this Yeah, this is hind. Sorry. I was so quiet because it was a mute. I uh, totally agree with cleman's long decision Okay, thank you anybody else want to join in Yeah, for what it's worth. So do I I mean, I haven't really done a lot of looking into this but that um It's a fairly compelling point. So Kind of makes it mood. Okay Anybody Disagree with cleman's point of view then Okay, so what I think I'm hearing then is We want to reject this poor request Right Yes, okay Clemens can you do me a favor since You articulated your concerns very well and people seem to like the way you phrase it Could you add a comment to the pr? And then once you do that right away. Okay. Thank you very much. Um So let me just make it a little more official Is there any objection then to closing as poor requests with no action? And clemens will have the comment explaining why Sorry to to say this but can you just repeat? Why we want to close this? I'm sorry. I zoned out for a minute I I guess my I guess my point here is if we if you close this one I would you also close one related to jms for instance if I wanted to standardize the mapping to that api yes Because jms is an api jms is an api standard. It's not it's not a wire standard True true. Okay So by doing that you're saying that you would have to To create mappings. I don't potentially for every single Messaging platform for instance directly one to one Well, you would have to you know, we have to go and and if you look at the bar that we have In terms of of what we find acceptable or not That I for instance idm doesn't even know how to how to document their own mq protocols Um, sorry dog Thank you for picking on me though. I appreciate it. Well, sorry, but that's just that's just the example though. It was the closest And so it's very difficult to define to define a specification That anybody could go and implement for wire compatibility And but you can go and use mqp Right, um, or you can use even the mqp 0.1. It was 0.9 drafted She wanted to because that's a wire specification, but anything that's That's proprietary. I mean if you go to jms, then you know, you can potentially map to a java api But the state of jms is not such that it's actually reliably compatible with all products um So I find I would yeah, I think I think we should we should really be principled about wire compatibility not trying to go and and Um, you know create that compatibility with some with some api What we need to have be lucky that the drivers actually do what what you are expecting them to do And basically strain it to a particular language, etc Okay, so so I get that and I I understand your concerns. I I guess is there Do we have room in this? group to support people that want to do For instance the jms binding would that would that would just be something that's out there in reference, but wouldn't be uh governed or Or sort of formally supported I guess Yeah, I think that's that's always um That's always possible and I think that's what we had this extension catalog where we were effectively referring out to other places um That's where that's where would that would probably live I mean everybody can for their own product can say how events look in our product as uh like this All right Yeah, yeah, okay, but the core at the core point. I think inside of this group is to create interoperability across uh languages and runtimes and uh and the wire Um, and I'm not sure how much, you know jms mapping given given where we are today Right if you if you had raced this 10 years ago or five years ago I would would have been leaning more towards agreeing with you Or sorry, but to say Um, uh, you know jms is something that we should support But we're now so far down the road with the mqp that it becomes a new point Yeah, no, that's cool So I mean if we're drawing a line in the sand and saying, okay We would equally reject those other sort of Mappings then then, you know, I I'm with you. Yeah, I get it. Okay. I would um One clear way to Say that is to say that it's not really a transport binding that you're Trying to make it's a mapping to another And it or another messaging format. So That that's it's named transport binding what you're trying to create is not a transport binding and as such It doesn't meet the bar Yeah, yeah, I agree All right. Thank you guys for that. That was a good discussion. I helped me get some clarity Um, anybody else any questions or comments? Okay, then one more time any Any disagreement then with closing this with no action with clements taking the ai to explain why we're closing it All right. Thank you guys All right Pretty casing clements. Let's open up your pr here so you could talk to that one. Give me a sec All right. What would you like for me to display on this one clements? um Yeah, this this section Okay, I got and then I made made some made some changes down downstairs to the the properties Um, so instead of getting into into case sensitivity or case insensitivity Which is complicated because Ultimately, we're mapping to and we're using multiple protocols where we can't change their stance on case sensitivity sensitivity or incident sensitivity And we've had now the the heroic Attempt in the pr that i'm referencing a forget the number of trying to rescue effectively the casing through Htp by introducing dashes um I'm going effectively in this pr. I'm going the other way. I'm saying you can only use lower case And which means if i'm restricting the character set effectively Which means no matter whether case case sensitive or case insensitive is allowed or not allowed Um, you can only use lower case and therefore, uh, it doesn't matter um, and even if someone does case and it seems like there is there's case folding being done Um by some frameworks, which then go and try to be smart about it and make it, you know mix case Or make it um or fold Um uppercase down Um, I'm just saying the only way to to to deal with those dark properties is for them to be lower case If you see them in any other casing do some framework um dealt with them You have to go and case fold them And that makes it easy and then I if you scroll down I renamed them And it's not so terrible That's I mean even if you if you look at the so even if you're if you're um Um, leaning towards extreme programming language aesthetics Um, I think that's acceptable I think if it's short it works if it's long then yeah, I think the 20 character limit helps Yeah, so I also made a rule if you go and scroll up again Um I also made a rule that says yeah, you know, you should be you should be greedy Um, and you should not exceed 20 characters length reason for that is simply that if we're sending uh jason You know canonical jason across the wire and we're sending um hundreds of thousands or millions of them And that gets very long very very quickly So being a little um mindful of the wire footprint that you're causing just for that metadata Is a good thing and so I made this a should rule But that's something that um, I think is a reasonable limit and If you have something that runs very long then it might be a good Opportunity to think about how you can make that shorter And if you really need to be over 20 characters, then you can but for the core spec Um, it's hard to see how you would Any other questions or comments for clemens? All right, I got one for you clemens. So I noticed that you you didn't address the issue of maps What was your thinking on that one? I didn't address the issue. What do you what do you mean? Well Our our property types that are maps uh, going to be encoded with dashes or something else or Are they going to be encoded as a jason object as the value? You didn't you didn't address that part of the issue at all I'm wondering whether that's something that we should resolve separately from this or should that be incorporated into this So that's that's in the hdp Mapping right and in the so what I wrote in the what I wrote in the uh in the pr in the comments Is that I didn't touch all of it So At the at the bottom there we go. Yeah, I'll modify the core spec for the purpose of the initial discussion um, so basically there's a there's a one There's a there's a March once through the the rest of the specs to go in and adjust that I didn't want to do this All in one giant pr where we don't know what we're talking about Okay, but but but to address your question. I think these um the model with the dash for hdp will will still be the case Um, that doesn't go away because you you just map them into the transport and then yes We lift things again off the transport into an abstract programming model What you need is you need to have a notion of like so that for instance The ce dash prefix in for hdp headers will stay Um because the reason for that existing is that you can go and have an abstract programming model Which only deals with our properties you can go and project it into hdp And none of those will clash and on the other side if you're collecting up your properties You know that everything is prefix with ce dash We'll have to go back into that into that property into that property bag your representation of the cloud event That you're then presenting off to the programming model Okay, so all of that so so that mapping stays so this is only this is only saying We're getting we're we're breaking out of the jail of case sensitive versus case insensitive by just allowing lower case Yep, okay. Thank you Now there was one comment in here This one. I want to just make sure yeah, I want to get your take on this comment um So this is nick. I personally think this comment is um irrelevant the the two issues that are brought up down here The second one's kind of the easiest one once they're upgraded, right? They're still all lowercase on the wire. It doesn't matter that we've gone from an extension into the Kind of the main spec because on the wire, they're all still just lowercase in the stk if we're You know, we know about that new property in the new version You know, it's the stk's job of getting that lowercase name and presenting it in whatever Appropriate case for the language is correct And then for the extensions again, I don't think it necessarily matters because the in all the stk models You are just going to be comparing everything against the lowercase version of the you know, if if you're Whatever map representation you allow people to put in the the camel case store or snake case whatever names it's then your job to convert that back to the Simple lowercase and we're we're done it. I think in my opinion this comment Isn't an issue If we were if we were here defining a compact binary format instead of of jason All of our attribute names would be turning into numbers Um, and then we would surface those numbers using those names in the stk But they would never turn into those names on the wire Um, so they would turn into those numbers. So that's the same that's the same concept here, right? We're making we're making expressions Identifiers that work on the wire and that you if you are working close to the wire You can go and interact with them easily you can identify them easy easily, but how they surface up in the stk Will not be a concern And if you look at very many different apis and how they represent wire concepts They use their most You know the idiomatic representation in their respective languages and runtimes and not necessarily how The wire what the wire representation looks like so I agree Okay, thank you Any other questions or comments for clements on this pr? keeping in mind This is just the Initial past the pr he mentioned that the digital changes would need to be made But the the biggest point here is to get a sense from the group in terms of where they like this direction I'll just lower casing everything and to refresh everybody's memory. This is going to be compared against christoph's pr Which we talked about last week, which is um, I believe the mitzvah numeric And a dash before all capital letters So we're going to have to choose between those coming up soon But in the meantime any other questions or comments for clements I Actually have a question Clements hold on just let me I think that was jam who's asking a question first. Let me let him go first Yeah, sorry. I forgot my hand up protocol. Um, I I I don't necessarily disagree with this, but I um, and I could buy into it. I think there are a couple of other Issues floating around or around this whole subject area. Uh, and I actually opened one Earlier in the week, which is somewhat related to this, but not directly so Given the amount of churn, there's going to be when this stuff gets implemented in a An all-encompassing pr. Is it worth Looking at those other issues and then rounding them all into one pr That would be my only comment You're talking about this issue that you raised right jim So that was one of them. No, I yeah, that was one I raised off the back of a comment that somebody made last week I think it was I may be misquoting. I think it was tins from aws Yeah, I think you might be right Yeah, I like I like I actually like the dropping the event piece since we're in control of the The outer envelope largely but but um That can be dealt with as sort of a tangential issue, right? Yes. I don't think we need to go and roll this on on top of this Um, I think we can make that a as a subsequent change. Yeah, and I think that's my point. Yeah, I mean it's not Reliant, but it's um, it's related Um, it's more to do for me with consistency anyway. Yeah, I've definitely agree it's related But I think we could do deal with them separately unless someone on the call believes otherwise Okay, so clement you you wanted to make a statement before we look at the next thing Yeah, I have a question and I that also plays into probably into the next one that's that's up there Um, I have been thinking about uh separators Um, and I think I'm even con discussing that here um Like can we allow a dot or a dash or or an underscore? Um, and I found um, that that's problematic in all kinds of different languages and runtimes If you uh, if you convert those names into identifiers Um, one particular question I have is for for all the scala fluent people because I'm not Um, what impact underscores have in scala? To my knowledge and I it's been a while since I've done scala did it shouldn't matter Yes, this is uh, Vladimir, um, I can confirm in scala does not matter. You can have underscores now You also have a one, uh, quite interesting property and that is if you have something that looks like identifier Surrounded with backticks, uh, that can actually contain even spaces and and other strange things So there is a great flexibility of Mapping names from various protocols and standards to something that works as a scala identifier Yeah, because the only language where I found And that was not deep research Where I was a little worried about underscores was scala because scala apparently has this Pattern matching with that is driven by underscores and I wonder I just wondered how much for practitioners that may be confusing if you are using the the the underscore Across the language and then also have identifiers that are using that would be using the underscore. Yes, when you have Isolated underscore that acts as the pattern matching mechanism and substitute for anything or any Yeah, but if the underscore is part of the identifier, it behaves like a completely ordinary character. Okay. Good. Yeah So thank thank you for for educating me. You're welcome. Thank you All right. Thank you guys any other questions or comments on this So I'm going to reply to the PR. I agree about the other comments about my comment. I'm tapi tapani Except about the response Stating that the SDK surfacing So to say New properties that have been promoted from extension wouldn't be a problem because that means The extensions and the core properties will either have to be in a different API in the SDK Or the name will change in the SDK because it will suddenly When you upgrade the SDK version it will recognize that core property name and a play word separation whereas it didn't before and Those if we can promote extensions in minor versions that means in the SDK It will either be a break breaking version or they will have different Um apis for grabbing those Yeah extensions So if I were if I were um, um So for a C sharp api can I can imagine which would be using Pascal casing I think only well known things in the current version would be exposed in a strongly typed way And you would have a an extension bucket that you have to go and reach into to go and get at the which effectively gives you the wire objects as a remind the remaining wire objects and that you have would have to go and interact with um, and If you then if we then go and promote in the next version, you know the now The the new property that that would show up as a as a Pascal case strongly type property. I don't think it breaks anything Sure, it doesn't break but that again, that means there's different apis You can't make one singular api for accessing data in a dynamic language, which doesn't need static typing You can't do it. You can't do it in idiomatic way. That's true. Yeah, it's it's not necessarily a problem I just want to bring up that this will limit the SDK design I agree And I think these are good good things to remember as the SDK developers start, you know playing with their stuff You know, see how painful it is for people This is all this will all be good feedback all right, what I'd like to do now Is uh, joshua. I don't think joshua is on the call, but joshua opened up an issue I think it was last night Suggesting that maybe we should consider a snake casing instead Uh This is there's somebody who would like to discuss this issue Or talk in favor or against I'll give you guys a second to read this in case you haven't a chance to read it yet all right Any comments on this one? No one wants to speak up Does anybody think this is a good way to go as opposed to say Clemens lower casing or Christoph's using dashes Uh, I I think this could have upsides. I want to say that camel case It's not a downside that camel case is the standard for jason. It's not really a standard for jason It's just used but so is snake case In a in so many apis Yeah, I was going to say that same thing Uh, it just seems like another option here and we're like I I sort of feel like what Clemens was saying about You know sort of the specification versus you know on the wire versus what we bubble up in sdk is it's The whole thing is starting to just feel like six and one half doesn't healer to me I just felt like saying that out loud Yeah, no, I'm sorry to get a similar feeling to be perfect on us with you, but yeah Okay, anybody else I was of the understanding that um, we couldn't use uppercase because of some of the Transport requirements meant everything will be lower case or something like that. So I think that's what goes down that path Yeah, is there a does snake case start with uppercase characters? No, no, it doesn't have to you've just got a delimiter in the middle. Oh, so that's just the underscore It's funny that everything has a name now Funny out of it There's a new one on me, but I learned something today, which is great I'm I guess snake case is better than underscore delimited, but you know more C++ case Okay, um, so is the uppercase an issue which means we have to rule out camel case and then it becomes between snake case and Just lower case. Yeah As said I was looking for I was looking for the separator here Go ahead No, no, but go ahead I mean, I mean I'm intrigued by his argument of the Uh of communicating a little bit more about the field Um with this with the underline that previously came with the case Um, I don't know if that's enough to convince me But I'm intrigued by it and I haven't thought it out through the transport binding. So I'll defer to clements on that topic Yeah, I'm as soon as as soon as anything comes that that isn't alphanumeric Um, there is various transports and protocols and encodings that have various opinions about what what is what So I'm I'm always a bit worried about So dashes are a problem for language bindings and dots are a problem for language bindings And the underscore is really the only thing that is that that works And then you have, um, you know Under score being a non permissible characters in other apis And that's why that's how I landed in there. I don't know how languages So I don't have a complete overview of all the languages that are being used And that's why I asked that that question about scala Um, so so underscore seems to be a choice. That's okay. And that's why I was looking for it um And so I'm not opposed to it. It's just I'm I'm just not allowing it is kind of abundance of caution Because I don't know how far our thing is going to go What if we preferred short like less your recommendation for less than 20 characters And avoiding the use of underscore Um is also a recommendation So if there are companies that want to go beyond 20 and use underscores they can But it goes against the guidelines So it's still permissible in some cases, but we don't recommend it Yeah Yeah, we can we can we can make a should not should not rule And allow it but that would that would really be the only that is the only separator that I would Permit and then I would um, probably try to avoid Try it hard that we avoided in our own specs I would I would say that should not with the underscore kind of defeats the point I think then it would be better to just not allow it Because if if there's if there's concern about the transports then the should not doesn't actually guarantee anything Yeah Yeah, that's always the problem with optional things Yeah, okay, so we're running a little low on time here. Um So it seems to me that we have three different options in front of us We have the ones clements talked about we have the snake case one and we have christophs Um I think people probably need some time to go back digest this think about it with their respective teams What I'd like to do is perhaps on next week's phone call see if we can come to a resolution if possible um, if not, we haven't even had four discussions. We will obviously but What I'd like to encourage people to do is to Add comments to respective issues or a poor request. So we get some conversations going there Just out of curiosity. Um, it was okay with you guys. I'd like to get a general sense of Where you guys are leaning towards right now just for the guys on the call right now So just out of curiosity um Are there people on the call right now who would prefer say joshua's snake case solution Yes, I would prefer snake case. This is roberto from adobe. Okay anybody else Yeah, I would prefer snake case over all lower case too Yeah, I'd like to at least understand it completely. Um, because it is preferable But only if it doesn't break transports Yeah, this is Vladimir. I agree. Uh, if it does not break transports, I would prefer the, uh, snake case because of much easier Readability and I'm concerned about for example the aspects of uh, tracing particularly distributed tracing where we are tracking Events that are going through a number of systems. It would be much easier for the uh, human reader to to correlate and see what is going on Okay, anybody else want to chime in on that one? Okay, is there anybody on the call who would prefer clemens lowercase everything? I would Rachel, okay Yeah, I would as well I also prefer the lower casing Okay, thank you Anybody else want to chime in? Yeah, I would as well Okay, jess Do you want to do this in chat? Well, no, this isn't a formal vote or anything. I just want to get a sense It sounds like there's definitely some people who want the first one Some people want clemens and it sounds like it's about even right now Uh, what about Christoph's? The one where he uses dashes between words. I'm sorry a dash before every uppercase letter No Like like one thing can I push for this like yeah, instead of just saying I prefer this one Which is like one like we could settle it that way, but it would like I would prefer if we like tried to summarize The implications of each and then and then I I imagine that there will be That a winner like a clear answer will emerge. I even like this might be this might be optimism, but I think that the um The implications of snake case will outweigh the pros, but I might be wrong And so I would I would really appreciate if we could like try to summarize why people Like if people on each side could try to summarize why like what they see as the overwhelming case like in very concrete terms I would find that Easier to like be open-minded too Yep I can suggest what I would observe Uh kebab case like the dashes are going to mean that you can't use them as bear work Bear access in languages like JavaScript where you can take a map and either access it with indexes or with a period Uh snake case Has a nice benefit of making human like multi-word things more readable But the downside is it makes a multi-word thing as much more likely and more bigger I would like to I would like to say that the um the Alpha numeric attribute names HTTP. That's a transport That's transport thing and the others touch the main spec so they're not directly comparable Oh, that's interesting to think about that So I would so if I I'm gonna I'm gonna make my edits I would say and I'm gonna I'm gonna do a pr on top of my pr Basically, I'm gonna do a fork once I'm done and I'm gonna add The camel case I'm gonna add effectively the underscore to the permissible characters And then we can go on and because that in the end then is the the snake case right So I can go and and effectively expand mine to include the underscore and then we as all Arguments have been exchanged for against we can then go and basically just vote to have it or not have it That sounds great. Yeah, and thank you rich first to get up But I was gonna say that after I got a sense of who was in favor of what so I make sure that there were some people Who actually did want each one of those? So, yes, please Put comments into each of the prs or the issue in Joshua's case so we can get some conversations going there in particular List the things that you think are And advantageous or problematic with each one so people can can see your point of view All right, and we'll see what we can do about Trying to resolve that next week I'm not sure Okay, I don't think we have time to dive into your next pr Clemens So let me just quickly go back And oh cool people have been adding their names there. That is wonderful All right Eslam are you there Eslam They dropped off. Okay. Um chat. Are you still there? I'm here. Excellent Simon Yes, sir. Okay. Vladimir. I heard already claus. Are you there camera? Have you spoke or not? Yes, I'm you excellent. Okay. I would have victor Victor are you there? Excellent. Yes, I can. All right. And what about the rinado? It's here. Excellent. Thank you Uh simon, are you there? Actually, I think I heard simon already once david You have me on the top of the list. Oh cool. Thank you. Uh david Wow, excellent. Dan burker. I know you're there because you ping me Uh chat. I got Nick I heard you. All right. Is there anybody I missed? I may have some duplicates on the list, but I'll fix that later Oh, actually I did one person Where are they? Eslam. Okay. Anybody I miss on the attendee list? Hi, I'm here. Erica. Erica. Excellent. Yeah, please. Yes. Excellent. Okay. Anybody else? All right. Thank you guys very much and for those of you Um, I want to talk about the shanghai meeting you probably just stay on the call And we'll just Roll over into that one, but everybody else. Thank you very much for joining. We'll talk next week. Thanks guys. Cheers. Bye. Thank you See you. Thanks Thank you. See you. All right 13 people want to stay on the call. I'm surprised. Oh, there we go. We're losing some All right, so let's see me Cleans, Kathy Jim you can stick around All right, let's see Here are these things. Oh, okay. We're losing more people now. All right. We are down to eight people one two three four five six seven eight. All right Let's do this There you go. All right so When you guys look at this list of potential topics Are there other things you'd like to add to the list? Keeping in mind, we only have two 35 minute sessions. So we have to keep it fairly brief Nothing Okay, I guess that's a good sign So, um Let's just quickly walk through these in terms of priorities for things that people think we definitely need to have there Oh, sorry, I misread I was reading serverless as workflow No, we have workflow down here I don't I don't know I don't know how that happened, but I just had that in yes, maybe it's late Sorry, okay, but So I think it's a given we have to provide at least a cloud events overview at some point at some point in that discussion um Do you guys think we need to review how we got here meaning an overview of the serverless work group at all or does that History and we don't need to dwell on that anymore It's good for an intro if you if you just want to say something about it Okay, so maybe say five minutes or so, right? I would not even spend as much on it, but Okay. Yeah less than five minutes. Yeah very short introduction is good Five minutes. Maybe a little bit more. Maybe just one or two minutes. Okay. We can do that one or two minutes. Okay Um skipping this one for sec. So status of cloud events. I'm assuming this is probably going to be related to Cloud event overview. So those will probably get lumped together in some fashion Yes, um workflow I know kathy you probably want that so that's that's an easy one for you anybody else have any objections including that as one of our futuristic topics I see like an obvious thing. I'm sorry. Go ahead. All right Varun you're breaking up really bad. I can't hear you Unless it's just me No, it's not you just you Varun are you able to Okay, we'll see what you can do Clemens. I'm sorry kathy you're gonna say something. Yeah, I think for workflow I'm just going also to for brief introduction, you know, not really deep dive into it Um, so how much time is limited? How much time do you think you need on that one? Um, so how many total time 45 minutes do we have 35 minutes for each session? Oh, okay. So total is 70 minutes, right? So maybe I can they are 10 or 15 minutes It's not a topic too early Okay, well, let's see how it plays out because I think I think we may have to Twiddle the times a little but let's start out with 10 to 15 minutes and see how Okay, so what about demo I'm thinking this may not be the best form for it. I'm not sure we necessarily have time to do it But I want to get your guys to take on it to to build to build a New demo for it. Mm-hmm I don't think we have enough time for that to really make it I think we say we're going to do this in Seattle, right? Seattle conference, right? I would definitely want to push for it for Seattle. Yes Yeah And recycle we can recycle the the prior demo That is true I mean I have all the bits. I'm I'm I wonder whether I still have some of the deployed even So I can I can certainly make I can certainly make the the existing demo work again And and Doug you have an endpoint. Mm-hmm. You have not thrown away that code I don't think we need to go and get everybody's endpoints back up but we can Uh Soul pop Do you know about so pub don't you? No, so actually yeah, so anyway, we'll talk about that later. But yeah, there's um, I actually I had an intern basically create a version of uh, of uh Twitter Yeah, so this is the so my end points still up and running and I I can add anybody's endpoint. They want to this and yeah, we could Do a demo of that. Yeah, perfect. Great. Fantastic We'll do that. Let's see if we have time I'll add it to the list and we just we'll see if we have time for that one Because the code is the same so it's all That's a nice thing about interrupt. It ought to be just working with this stuff that I have right, right? So let me do this. Let me move the workflow here. So what's next for serverless? Aside from workflow, do we have enough topics to potentially mention to make this a a discussion point Have we reached the consensus of what's next for serverless work group? No, in fact, I think So I'm not sure whether it's good to Yeah, if we included this one, I kind of thought it would be more like here's some potential things we've thought about But that may be too much of a tease. I don't know. Yeah Okay, I'm not hearing any great love of that one. So we can cross that one off right now What about this one cloud event persistence? What's that? What does that mean? What is 276? Let's see. Take a look at that one I think this is a very specific topic. I feel, you know, it's not in the same level as the other topic This is a very specific I don't feel we should include the very very specific because if we include this there are many other Topic about cloud events, right? Yeah Clements, you disagree with that assessment? No Okay, so I think that makes sense Kathy cross that one off so So, how many so we how many talks do we have to we have a deep dive? I'm sorry We have an intro and a deep dive both 35 minutes This feels like we're light on topics to be honest Well, how much would have pad out the the demo piece? Well, not only that, but I guess we do have to allow for time for questions and answer So that's five to ten minutes there Yeah, we definitely need that, you know, so we can get some input from border You know audience. Yeah So five 10 oops 50 five 10 minutes Okay I think the demo probably could be very low priority because we already have that demo and most people I guess already seen that Okay, so let me just move things around a little based on but you should don't underestimate the The depth in which we can go just on the existing specs Because we have transport specs. We have amputee amputee in an hdp Um, we have a we have the the webhook spec that is something that's that's general generally useful Um, there's I mean I can turn this into a 90 90 minute session if I want I'm sure you could Don't be don't be too worried about us not having content that is is easy to fill So, okay that so that's interesting So it seems to me in an intro session If we have you know one or two minutes of what was what the service working group did and how it led to cloud events And then we do some amounts of overview and status in an intro That might be a nice introductory session. Yeah, and then a in a deep dive Talk about some of the Deeper level things like some more deeper dive and on the transports for example Get into the workflow Uh, don't know where to put the possible demo where that's an intro deep dive, but maybe classify things that way I would I would do the demo at the end of the intro session Okay without without I would talk about the demo as a scenario in that session and then basically make the cliffhanger of Oh, and if you're interested In how that works you got to come to the next session Okay So intro um, I would like to add that um In the intro we also like, you know, so in the deep dive we also have some cloud event session, right? So we need to add that not just workflow, but also I was going to do this. I was going to do cloud events And also in the intro, I think we also need some Overview of the workflow too. Otherwise, it's a little bit Weird why you know in deep dive we mentioned workflow, but the intro we do not mention I think we should also same thing. We should talk a little bit about, you know workflow Introduction about workflow So maybe do a little bit of cheese there to bring people back for the deep dive Yeah At least mention the SDK SDK, hey, I'm glad we can hear you now. Yes SDK that is excellent So do you think SDK would go into intro or deep dive? That would be part of deep dive too. Um SDK, okay I think both, you know a brief intro of the SDK and then To see whether anyone would like to do um I'm not sure is anyone doing deep dive for SDK Austin is not going right. Austin is not going. I can definitely talk to that in terms of what they've been doing because I've been attending those meetings Okay, I don't think that's a big deal But I do like the idea of a little bit of a one to two minute teas of workflow SDK to bring people back and then talk about them in the deep dive Yeah And I think the real question here is what from this list of The cloud events overview do you want to pull down into the deep dive because I don't think we necessarily have time to talk about all these in that session Um, yeah, especially like transport specs and all I think can go in the deeper dive Okay, let's do that. Yeah I think for transport if we really want to talk about it can take the whole session is not enough So I think that need to be very brief. Maybe we just mentioned what kind of transport we support Uh, and the why that's probably enough Okay anything else What do you mean by some use in the overview of the samples? um I'm trying to remember what I was thinking of from I think I wrote that I think I was just trying to get I think I just wanted to show people what cloud events look like and I think that's probably That's probably automatically there when you start talking about what are cloud events and the overview of the spec I don't think we have to call that out Okay, I think I think we can ruin that It was cases and then okay So hold on a minute. Let me do this let me Grab you out of there put you there Put that there so okay, so that's what we have so far Okay, we don't have a birds of feather session right last we have last time We do not we can I I would like to actually turn these into birds of the feather Oh, I'm sorry. No, no birds of feather that would we turn that into more of a work group meeting, right? Yeah, it kind of ended up like that. I think yeah, yeah, so I know we don't have one of those set up We could definitely do one. I don't think we're gonna have enough people to do a real meeting No, I think we had a different work group meeting what we had a bird of feather session with like People who are not in the work group, right? I think that's what we did at Stockholm or whatever it was Copenhagen. Did we? I can't remember. Oh my gosh. I'm getting so old That's fine. These are the two sessions we have Yeah, but yeah, um, but I would like the q&a session at the end of each to be almost like a bird of a feather So it's interactive Yeah Okay Anything else I I feel like the deep dive is still a little light. I know Clemens you you said we could ramble for quite a while there, but Are these two sufficient you think for I think I think if we if we if we should only show the demos Uh, the demo kind of from the surface And say this is the scenario and explain the scenario basically make make this this session a As we would call it level 200 Um, the first the intro which is like take the light on tech and probably doesn't show much code Then the deep dive if the deep dive starts with Um explaining that code that's already taking um some time and then um, and then I would And then I would go into, uh, you know transport basic transport specifications and event formats and how that all hangs together and why it's built that way Um, and then we can go into workflow 35 minutes already becomes tight when you when we do that. Yeah, you're right. I was very tight actually Yeah, maybe we we can at some time like this will turn to 10 minutes. Yeah, yeah that this this Yeah Yeah, we do some whoops. Yeah It's not a very tight So for workflow, I want to say I I want to talk about some use case So I would like to get some input use case. I think it's important And then it's an overview of the workflow Model that I think that's already easily take 10 minutes. Yeah use case and then workflow model Yeah, okay, so Okay, it's fine just the overview. Yeah, okay, so let's focus on the intro here for a sec So we have some times here. I think those work fairly nicely um Intro timing we have one to two minutes just for this Um So the tease is one to two minutes So let's say we have 35 take away 10 that's 25 maybe five minutes between the first and last Session so that takes another 20. So we have 10 minutes for Here and 10 minutes for here and that does not include the potential interop demo I think for the status of cloud events probably five minutes is enough because the status, right Not and then for the teaser about workflow SDK both. I think more probably need five minutes Just easily you talk about several sentences, you know, what is Yeah, what do you guys think Yeah, that's good Comment any comment on that um Well, we know 10 15 20 If we don't have any time for the demo that might be we may have to play that one by here Unless you guys want to definitely allocate some time for it No, we don't have to I think it's fine if we don't have that demo because we're going to have another one in Seattle And then we already have one before So we can do this so time permitting But we can we can announce they work don't have a demo in Seattle. We can say something like that No, no, but it doesn't help anybody who's in the room um The demo that we had is good enough And and if Doug has has it I would I would literally just just use that as the cliffhanger like it's a It's a one minute two minute Oh look at what we have here and you know talk about the The scenario per se And then say if you want to see it if you want to see the detail then come to the next session so Do we actually have that as a topic in the next session because I don't see it on our list Yeah, that's that's what I would that's what I would do. I would I would then go and and talk about um How the demo works and I might do this um Actually after the the deep so I would probably do the deep dive and then go and explain the demo Once we've done the deep dive like now you explain. So basically you start with here's the htp mapping Here's the the um the webhook spec Here's the jason thing. So I would probably focus on those and then mention in kp and empty t And then say oh and if you were here for the previous session, you remember this demo And now let's go and take a look at what we just talked about in code Okay, so when I think I'm hearing you say something more like this So teasing on the workflow sdk and demo with with about five minutes or so on that Okay Yeah, so we're not going to do a demo. We're just going to talk about the demo right is that We're just gonna we're just gonna show us some some web pages We're not gonna we're not gonna go and show any code in that in in the first talk What kind of web page are you gonna show what what doug just showed? That So the integration scenario that we had is is effectively this is the this is the non twitter twitter version of this Right. Yep. And so that's what we're going to show. We're going to explain how this is we're going to in the intro session We're going to we're going to explain That there are various Publishers that are raising events and they're being pushed and they compose this feat and So we'll talk for a minute about that, but we're not going to talk about how that's being done for that people need to come to the next session And we can we can still some of austin's slides or i'm sorry He has one slide in particular that shows All the various players involved and and we could quickly talk to that. I don't think that Yeah, I think it's good. Yeah, I think it's good to show, you know, all the players Remember last time we have we show so many companies Involved. Yeah, I think it's it's good to show like there's a lot of you know participation in this In this work group. Okay So let's do this Kathy I assume that's an easy one you want to talk about that In the workflow. Yeah I can talk about it. Yeah, mm-hmm. Are there other So veroon or clemens or it gets Kathy Are there other topics on here that you would like to own in terms of doing the presentation? Actually veroon, are you going to be there and saying hi? I'm not sure, but I don't think I feel uh Yeah, I don't think I Knowed well enough into some of these topics to talk about them. So I think you guys probably have it covered. Okay in that case Kathy clemens. Um, are there other topics here you'd like to talk about? Let me see take ownership of Uh, so I would like okay um, I would Take the transport specs Okay, so so keep in mind Um, I given it's only 35 minutes or actually more like 25 minutes because you have to leave time for q&a I don't think we should have more than two speakers per session. Yes. So I would like to be in the deep dive That's what I thought. Okay. So that's why that now Okay, so let's focus on the deep dive first. So clemens if you do the cloud event stuff. Kathy you do workflow Yeah, sdk Do either of you feel comfortable talking about that or would you like me to step in there? I have not even been in the group Okay, probably dog. Yeah, you can definitely do that. That's not a problem. Okay Uh, okay, let's focus on the intro then You guys are there any sessions in here that jump out at you is something you want to do? Um, if you like I can talk about status of cloud events If you like or dog, you can take that if you like I'm just I don't personally I don't care. I can do any of these topics So I want you guys to get first choice basically. Okay, I can talk about that status cloud events Okay I can I can so let me let me say what I'm gonna volunteer what I'm gonna volunteer on and then we can go and so you'll probably separately talk about the The the who speaks about it. So I'm happy to go and turn the technical parts of the specs into slides So I can do the overview the slides for the overview um in the sense of here's what the spec actually says And Then we can still decide who's gonna who's gonna talk about it If you want to talk about it then you should Well, okay, so I I tend to think that the person who's going to be talking about it sort of Owns the slides now whether they write it all themselves or they steal it from other people or get help That's up to them to decide Okay, I'm more interested and right now Who wants to do the talking? Doug, do you want to do talking? I don't care. I will yeah, I have no problem doing that Because I've done it before so I don't mind doing that. Okay, great All right, there we go Yeah Okay, so this Kathy, obviously you could do a tease about the workflow um Do you want to Also talk to the demo or clemens. Would you like to talk about the demo? Um, I can talk about The demo if you want to be there up there with three people then I can talk about I'm trying to figure out whether it makes sense because it's because it's your it's actually the version that you're interned in Uh, it will make more sense for you to do that. So for for you to to split that session Okay, I can do that Is that everything? So I want to talk about this the workflow sda demo, right dog I will talk about I will do the the tease of the workflow sdk and the demo. Yes Okay. Yeah, sure. Um So this I can help with the slide on a workflow. So this well. Hmm. See this feels a little awkward because Kathy you're only there for five minutes um Hmm Well, what if what if we did this what if we split it? like this Whoops Will that work for you Kathy? Okay Just because I don't want you to get up there Only talk for five minutes and then turn around and step back down. That's that will feel a little awkward Yeah, okay So maybe that's five minutes and then two minutes Actually, let's do this let's do four I know we're not going to be that precise but Just so we have a general sense of how long each one's supposed to be Okay, okay, and Clemens will do a deep dive on the demo Okay, so Oops, let me get this out of the way so you guys see you can see the full screen. Hold on a second Okay, so does this As of right now look like a good flow to you guys Yeah Does maybe maybe I want to have 15 minutes for the for the transport specs and demo Okay, I don't think that's a big problem. I think we'll probably have time Okay, anything else? No Okay, so tell you what why don't we do this? Why don't we now um Stop here and then we will Go off and think about this in our particular sessions And maybe we could talk again after next week's phone call just like we did today To see if people have any concerns about the flow or questions or something like that Talk about the next steps. Does that sound good? That works Okay, so for the SDK I might need your help, you know, because I did not run that This group meeting Yep, not a problem I'm just trying to think Scott Yeah, yeah, that's fine. I don't yeah, that's no problem. I was just thinking um I think scott actually might be really busy with other things. So he may not be able to talk Varun, you said you don't feel comfortable about that. That's fine Nick I haven't I don't know If nick wants to talk or not, um Let's assume not because I don't I don't even think nick has actually been in our phone calls So he may not be a good person to do it anyway, and I don't know who Rue is So okay, I just want to make sure that we didn't exclude somebody from the potential speaker list. So I think we're good Okay Okay, yeah, so let's do that. Let's talk again after next week's phone call assuming that works for you guys I'll send out an invite and then we can see if we have any additional questions or or suggestions for changes at that point That sound good Yeah, so so what would you like to should we have some slides ready so we can go through them and then review together Would you like to do that? Yeah, tell you what let me let me do this before otherwise I will forget so some ai's So, um Right for next week's call Same Same day and time Um Start a google Our point deck For people to add content to yeah I gotta do oops Times two gotta do two of those anything else in terms of next steps In terms of action items I think that's it Okay, so what I don't mind taking the I'll do these things. I don't mind doing that. That's not a big deal Give me something to make it feel productive Okay, anything else you guys want to talk about then? No, uh, since this is the first time I'm going to China for a Little Foundation conference Do you use the invitation letter that they give on their websites? Uh, actually I already have a visa, so I don't have to worry about that. Um I don't know Go ahead. Okay. No, that's fine. If you don't know then that's fine. I'm probably going to go then through our corporate Our corporates mechanism I I I was I went to china last year and I was stupid enough not to do a multi-entry visa And I'm gonna have to fix it now. I think yeah, I would definitely recommend getting the 10-year visa. It makes life so much easier Yeah 10 years. Yes. Yes. Yeah, that's right. Use 10 years Later we'll we'll I mean we'll do it. You can get that Give the visa. I I have the feel I have the feeling that uh, I'm gonna go to china more often now, so All right All right in that case cool. Um any last questions comments things to talk about Uh, no All right. I believe we're done then Thanks guys. All right. Talk next week. Yep. Bye Bye