 Hey, Clemens. How's it going? It's going well. Hello, Doug. Yeah, that's good. I Have looked in advance at the at the agenda Very small Yes, very small. And then I also I also thought well, I'm very glad that Doug is doing this Okay, what's the connection there I'm not quite sure I see it Just look at I just looked at the document like oh, it's everything is there already Doug is I'm thankful that Doug is doing this because This group would not be What it is if you weren't there Well, I appreciate that. Thank you That's all I agree, but thank you That is that is the truth This is actually one of the highlights by day I remember my wake I should say I the only problem I have with this group is the meeting being on Thursday means that You know, it's near the end of the week And so by time, you know Thursday's shot by the time this is over because like other things going on And then Friday is either, you know, you're doing your normal work Or you're kind of slowing down a little because it's almost the weekend kind of stuff And I keep thinking okay, you know, I don't necessarily have to to go back to some of my action items from the serverless working group I could save it either for the weekend or early next week But then the next thing I know the weekend's gone And then I'm I'm looking at Monday and it's like oh my gosh I wanted to get this stuff done I know I have till Tuesday night to get it done because of the deadline for people to be able to review it And the next thing I know it's like after Tuesday and it's like oh crap and miss the deadline So I'll just wait till later and then it's like this perpetual thing of never having the time to actually work on the stuff I wanted to work on There are there are people in other in other groups like this which are Definitely far less well-behaved Than you are I have people who get chased around for this same same work item for like half a year already Yeah I have so many high hopes for things I want to do on the weekend and I end up just like Vaging out or doing other things Okay, here we go, uh Tommy are you there? Oh, no, he has no microphone. Glad Hey, that good morning. Good morning, Tommy Yo Randy Are you there? Hey good morning. Hey, is this your first time in? I can't remember It is yeah I'm with rxm and we try to just sort of keep keep up with what's happening rxm You guys have been here before right with some other other people right usually christian attends, but he couldn't today Okay, I thought that they recognized the name. Okay, cool. Thank you and welcome by the way Thank you Hopefully scott will join soon because he has an interesting little demo to show us which is kind of neat Oh, wow, it's almost the top of the arm where five people was going on. Um, by the way for, uh While we're waiting I think I think in the in the schema registry spec There will be the first use of cloud events for cloud events cool Because um, I've been thinking about how to do um replication And so because we'll have to go and share the schemas obviously and I think the way the best way to do this is to raise cloud events Makes sense to me. Yep cool So that's kind of how this is all going to tie together is by By raising events whenever there are state changes and then Whoever's subscribed can go and pull this the state changes or the the respective skew it has changed Yep, it makes sense. I mean, that's what we're thinking about doing with uh The discovery and points as well, right because I know if you want to subscribe to see changes That's right. So that's that's how how we generally should Yep, should be good your own dog food. Hey mark And ginger are you there? Hi Doug. Hello and well Hi, hello and slinky Hello. Hello. Hello So for folks on the west coast, how are the fires looking? I have to actually check the news in a couple of days. Are they dying down is smoke clearing they may know Mark, I think you you you can you can see a picture of this Fog and smoke outside That is ugly Yeah, there's actually a good island view out there, but not today or enough for the past week Hmm interesting First day it got into moderate in southern california. It's been worse the last several days Hello class Hello And mr. Scott Brian either Hello And mr. Baldwin Hello, hello Ryan hello. Hello All right, just another 30 seconds or so we'll get started Rando I'm not gonna Say your name properly. So I won't try rondo. Are you there? Yes, I'm here. It's okay And which company are you with if you want to be associated with the company? Yes, I'm working for a sap but but Yes, an open source Okay, cool. Well, welcome We have a very short agenda today, but on the positive side Scott is a cool demo to show Oh, actually I can kill this AI right because you put put put the forward a proposal already, right slinky Yeah, I cool All right, Jim welcome Hey, all right. Why don't you go ahead and get started? It's three after Um, what am I done my mind just so I stopped there was like, okay AI is uh, okay community time anything from the community people want to bring up. That's not on the agenda All right, we do have an stk call right after this one this week. Um I don't think there's anything on the agenda as of right now So if you have anything, please go ahead and add it before the end of the call. Otherwise, it'll be a very short call Interrupt discovery. I'm not sure There's anything worth mentioning from last week Because I think actually a lot of people had to drop off for other phone calls Scott or anybody else who was on that. Can you guys think of anything worth mentioning? Okay, not hearing anything Moving forward. I don't see team around the call that give an update on workflow. I do believe they've they voted on a new logo Um, of course, I don't have it handy to show you guys, but They're their work. They have a new logo that I want to I'll try to find that and place it into the web Into the s like channel. See if you guys are interested All right before we get into the core part of the agenda Are there any other topics people wanted to bring up that I forgot to mention? Okay, in that case Scott what I'd like to do is stop sharing So that you can show your demo Whoo, okay Let me uh, let me see here man Okay You can stare at my sweet sweet prompts So I have a little go program that's implementing the discovery api as it sits in the repo right now I didn't have a chance to implement epoch yet, but I kind of want to I want to show what uh I think discovery aggregation and propagation looks like so um I'm going to set up a scenario here. So I'm going to talk about this as this is the left box middle box and right box The left box is going to be uh, this so this is all local hosts. There's no kubernetes or anything. It's just running locally This thing is going to run on port 8080, but um, and then ignore this downstream thing I have well, maybe I can show you the Kind of what I'm seeing this stuff with I have some config I think this one's going to be uh xyz It's just some static pieces of Discovery in point. I actually think there might be a bug where I'm dropping types, but I'll fix that later It's not important for this Uh demo, okay, so let's start the server It's it's not really that interesting. It's just the discovery server. So we can uh curl local host at 8080 and ask for its services And we get a bunch of stuff. That's cool We can pass it through jq and kind of get like a the preview of it And like I said, it's dropping the events for some reason. I'll go back and fix that But that's not that important what we can do is uh ask I'm using jq to just strip out everything except for the service name So we can see what services this particular discovery endpoint is aware of It's getting some errors because of uh future demo ignore that So we'll set up a the middle box. This one's going to run on 81 81 and its downstream is going to be 82 Did I do this backward? No, I think we're fine Okay, so we'll run this one And we'll run its Right, okay, so the left box's downstream is 81 81, which is the one we just started up It's getting uh, can't talk because the the next server hasn't started out, but here you can see Service c outdated. I'm kind of I'm trying to say that this has a copy of service c, but it's Out of date in terms of like what the most recent see What c looks like and you can see that that propagated over to the first server So now it knows about x y and z but also c and d but c is outdated So we'll start up the final server here We'll do the simple version with no downstream So this is going to start up The server that hosts a b and c on port 82 82 So we'll run that We'll watch its services And now we can kind of see the the a b and c propagates Down the chain all the way to the left side, which that's neat. That's neat Where it gets fun Is you can make a ring If if you so like you can imagine like uh in a very complex system that you might accidentally make a ring Uh unintentionally So we'll start that so the left hand's downstream service I'm sorry, the right hand's downstream service is the left hand server. So now After a couple seconds this thing is going to pick up All of the x y z it also picked up d. So now everything knows about everything else, which is neat Which brings me to why we need epoch So i'm going to start Based on timing. So this the middle server here has Has reintroduced service c as an outdated thing But it's going to continue to propagate And now It starts walking the ring Which is kind of entertaining to watch And the reason they can't understand how to reconcile the outdated c versus the this updated c Is because it has no way to understand which one is the most relevant one in this ring So it like it'll never actually fix itself. It'll just cycle forever But That's my demo Very cool, but it explains why we're going to talk about the next pr on the list Any questions or comments for scott? Thank you scott. I love it. That was beautiful I'll paste a link to the demo so you can run it and play with it if you want. Oh crap. Hold on. I'm sure the wrong thing Let's try this again There we go. That's the right one All right No questions or comments for scott Okay, again. Thank you scott I liked it all right, um So tell you what since he just talked about the epoch thing. Let's talk about that one first So unfortunately both of my prs were updated. I think technically too late to do any kind of vote today, but even so I still think people need time to review it. So on this one This is the epoch one. Um I basically took what we talked about last week and said, okay, we're going to go with epoch, which is just a number It's an integer Uh, it has no semantic meaning people can technically put anything they want in there, whether it's just a counter Or it's an actual unix in time stamp kind of thing Um, that's up to the implementation choice. The only requirement is that it must always increase as it goes forward As the service entry is actually updated And that's basically it in terms of what I made here in terms of changes Are there any questions on that? I'll give you guys a second to actually read What I wrote there Is that consistent with what I think we agreed last week? Yeah okay Okay, um Unless there are other comments or questions I'll leave it for you guys to review it for wordsmithing type stuff But if you guys think in general it's heading the right direction just need to We're about wordsmithing. We can do that offline. So any questions high level questions comments All right, cool. Thank y'all Uh rest apis again too soon to Vote or anything, but So this one, let's see if I can remember all the changes I made so I think the biggest change that I made was To split out the apis into two sections. Um Let's ignore that for a minute. I split it into discover apis which has basically just the gets And it's a get of services with a get of Services with a name Okay, I think that's what we had in there before so I didn't I didn't really change a whole lot in there Other than I added a little more clarity around what the response codes could possibly be Uh mentioned you can use pagination in case the list of services is too long Um again, just return code type stuff. Hopefully nothing in there is too shocking But then the big change is the management api section Here we talk about the put the post and the delete And I decided to try to make a generic asynchronous message processing section Because I found that when I tried to incorporate the logic of how to do async into Put post and delete it became kind of repetitive and made those sections look more complicated than they really were So I if you guys don't like this I can I can reorganize it, but I thought it might Flow better to say, you know what we're going to put asynchronous processing in a complete separate section on its own And it applies to all the other Management apis in a universal fashion um However on the post side of things make it so that you can Obviously add a new service entry by just doing a post This one is it's expected that there is no id associated with it So one will be assigned by the endpoint if I discover endpoint However, if you're doing a put that in cases for example, you're doing an import Or you just want to update an existing one Obviously the id is already in there and therefore it must be Inside the service entry as well And that is fairly straightforward. I do talk about how the id needs to make sure it gets updated During the up during the put because it is an update However, um, there was one catch. I wanted to point out to make sure you guys are aware of this. Um Okay, so down in here um When you do an import um If you if you're trying to do an import But that id is already being used by the discovery service I couldn't think of any obvious way for us to know from this discovery endpoint side Whether we're doing an import versus an update Um, so I decided to add logic in here that says well if you as a client if you're doing an An import the thing already exists you have to first delete it because the problem is I don't know whether to update the epoch or not Right because on an update. I should it should get updated on an import. It should not So it got a little funky there. I'm not sure that's actually the right answer I think it might be a too big a burden for somebody to do a delete first or to Check first if they need to do a delete first because that's three requests, right? Do a get do a delete then do a put? so Maybe we need to add a query parameter or something that says Import as opposed to a generic update. I don't know I was hoping maybe somebody else that have a more brilliant idea or any idea whatsoever Because I'm not happy with what I came up with but it was late last night anyway, um That's about it. I do allow for deletes to be asynchronous as well um Anyway, let me go ahead and pause there. You guys can read it on your own Hopefully it's not too earth shattering. Oh, I should say for the asynchronous stuff I thank you klaus for the link to how odata does it? I didn't exactly take what they did but I used some of the similar thoughts they had in there um and clemens you had a comment last week about trying to do 301 redirects and all sort of stuff and I'd be honest. Yeah, I couldn't bring myself to do it. It's just it just felt too darn tricky and the idea the idea of sending the payload every single time Um, just just bug me. I could be arm twisted and doing it if you guys really want I just I just couldn't bring myself to do it without more arm twisting So anyway, that's I mean, you can't if you want it's okay Gem your hands up I just uh, maybe it's not directly related to this when you do a delete Is that a hard delete or a soft delete? I mean it is all notion of history vaporized at that point I actually did not talk about that yet. I was kind of assuming it's a hard delete, but If someone wants to offer something different I didn't think about it. I will think about some implementation detail Could be if it's a soft delete gem Who is who could get to that information or is it just the the operator? I think the soft versus hard delete might matter for the downstream consumers So if like in my example if the middle ring deleted the d service, how does the downstream How does the how does the upstream server? No the downstream service understand that? D no longer exists because it doesn't exist on the payload anymore But there's no notion like it's gone If you if you make soft delete a thing in the protocol then You also have to figure out how to go and resume things and and you really have to then include collision warnings because you can't create something that doesn't list but There's some there's some deleted record in the back that might cause and Conflict anyways So that's a slippery slope It is I mean I'm just And again, maybe maybe I'm misinterpreting but if I'm a client that's using One of these services and suddenly it just disappears under my feet. I mean Where's the life cycle management of This service is about to go away Yeah, so you you know, you should stop using it before it just vaporizes from Any directory services that are advertising it and I've got a business process that relies on that Do we have a status field? We do not I've yeah, I've seen some other specs do something like a um I don't want to say expiry. That's not the right word It's a sort of flag that indicates it's deprecator or something like that, right? Yeah, we have a we have in our services. We have a status field which kind of says you know creating deleting And then the various states of liveness and that might make sense to go and introduce that here That you have that you have a status which is the thing doesn't really The thing is not deployed right now Or it's not reachable But it nevertheless exists Yeah, and and I guess from my standpoint it's the other angle where You know if something is deprecated you shouldn't maybe advertise it But that doesn't stop me from continuing to use it. Yeah until You know until its replacement has has arrived. Yeah, yeah, but then I think the status would do their job, wouldn't it it would if if that's the If that's the proposed mechanism, I I wasn't aware that that's Data's went down to that sort of level. We have to if you deprecate something I'd also expect to know when it's going to be retired altogether Yeah, so otherwise, how can I how can I plan my work? Yeah, it's something we face internally Yeah, PayPal with people wanting to create new stuff all the time and change versions And having an understanding of something the fact that something is deprecated therefore I shouldn't use it I shouldn't build new stuff on top of it, but it will continue to operate for a certain period of time So it's more That you're getting that information across and if the delete is simply I'm trashing this record That that so I think a slightly different function. You're right Jim would it make sense for you to open up an issue so we could have discussion because I think it's related but it might be A require more thought process. Okay. Yeah, thanks. Cool. Thank you. Okay. Scott your hands up Yeah, what do you think about adding a labels A top level field where you can it's just a string string map Where you could put metadata around Stuff and then potentially Convention says that something gets labeled as deprecated true You want to open an issue to Bring that up because I think it's related to gems But I think it's a label thing in general sounds broader than even what gem was looking for So I think both of those things might need separate discussions Okay, cool But it sounds interesting because I do like the idea of people people even add extra metadata in a well-defined location Sanjay, you do you want to say something you didn't raise your hand, but you came off mute I Agree with Jim. I wrote that up in people's API guide and I was just going to post a link For that. I think it's on the public guidelines. I'll write it Write the link here for the deprecation. Okay, cool Thanks, Jim So based upon that conversation though the one thing that popped in my mind was Whether we should add a sentence in this in the geth section that says Should the receiver of this output assume that an entry that just that when missing has now been deleted It seems like they have to don't they Could you repeat that statement? So if as a client if I do a get to a To discovery endpoint and I get back a list and then five or eight minutes later I do another get and get back the full list, but now there's less items in there Should I assume that the items that are now missing have been deleted? I would assume so Yeah, I would assume so too. I was thinking we need to explicitly say that though so people don't Know interpret it differently. I'm not sure how else they interpret it, but Interpret not all of them do interpret it differently Well in that case the epoch revs So it should be that the everything under that record is the current state of truth Say that one more time you lost me. I would how would epoch play into there because the the entry is gone epoch wouldn't even exist, right? Well, this oh the total service list I see Yeah, okay I I think we need to figure out how to do that because like in the aggregation case that becomes very complicated because If if right if D disappears I don't know would have deleted because it could have come from some other downstream And I'm doing a merge of things. I know not I don't I don't necessarily know which Service told me about the that aggregated service list right Sorry, hold on my my screen just is a really weird stuff So I'm not sure what you guys are seeing from sharing perspective. There we go so Should I should I open up a separate issue because it sounds like this this might require some more thought process Beyond just trying to introduce some the some management apis I think it's a good step moving to the management apis Separating from discovery and I think we can continue to work it out in the repo. I wouldn't block merging this from Okay Okay Eric your hands up Yeah, this this might be way too out of left field. Um, but I thought that was coming up for me while I was listening to all this good discussion is that There's there's kind of this discussion of this materialization as a the source of truth for these described services and It seems to me that it's maybe a little ironic that We're not instead offering a kind of stream of events or A log of events that can be just consumed that says hey The the last all it here's the entire history of What what I know about this service and the last entry on that service is it it was requested to be deleted um I don't know if that's terribly helpful, but It's it might be potentially a different way we could approach this rather than worrying a lot about how we specifically materialize the State of or of our knowledge of the service we could Instead just keep a history and here's our latest you go for that latest There's nothing there you go for the history and you get this a the last entry in that history. It's this was requested to be deleted I think that's a very reasonable reasonable thought And actually before before most people joined I mentioned that certainly for the for the service registry spec I'm planning to have state change events that um That do what you're just proposed and that is like whenever the the state changes um that you can then Learn about that state change as a subscriber and Um, then basically keep track of it and then for Attaching as a fresh subscriber It's fathomable that um, you know given that your delivery path supports it you could basically subscribe to from the start And if you subscribe to the start then the existing state of the service registry is basically Played to you as inserts as insert statements. I don't think you have to keep the entire event history of you know all the sense and and all the creates and deletes and everything but You should it should possibly be possible for a subscriber to get the state of the registry being read to them as a sequence of Insert statements, if you will So so that's something that I certainly have thought about for the the For the service registry And it might also be for discovery that discovery synchronization on in the on on the in flight happens through raising of events but there will always be the case that um delivery Is difficult and that you have to go and effectively do this from a client that sits behind the firewall, etc. Where um, you need to have some imperative way of of Of manipulating the store kind of from the outside with in the crudway. So I think what we're doing here is not Is is useful But I think having an event driven way to also do synchronization will also be great. So I second that So is it it also means that we are adding the requirements for consistency For implementation Because the events Uh have to be presented in a consistent manner, right from any you are showing the demo and it was Kind of eventual consistent Uh kind of scenario So anytime you try to access the latest event, maybe no, you know, with whichever server you are hitting it may not have the latest Uh event But dns is like that, right? One way you could do this is You keep that the top level get services And then you introduce the services slash epoch or something and you ask What's the what's the changes? What's the changelog since this last epoch that I knew? Yeah, and you you get that sub list, which is a really interesting idea Yeah, that's that's basically what that is. It's like I here's the last change that I know about And uh, and then you basically just say I would like to have a sequence of events since that time So that's actually interesting. So hold on a minute That would put a new requirement. Hold on. Do do do because I like that idea, but We would need to make it so that the epoch doesn't just go up For that one service entry it goes up across the board So between two service entries you could see which one was updated latest, right? Because otherwise Scott you couldn't you couldn't have a global epoch for your get That's right. You would that would only work for the single entry, but We could try to I mean what if the discovery services list had an epoch in the header or something Like a I don't know maybe Eric has an idea of how other services would do this It's so tell you what Eric could you write that up in an issue because obviously there's interest from the group in that And that sounds really interesting But I guess my question is Is your is your idea there? Is it to replace something that's in here or do you think it augments it? Oh goodness, this is the the big um the kind of worms that I'm okay, I guess. Um Hey, I don't think that there's anything inconsistent about using a uh log of events to create the Materialization that we've been talking about interacting with via this rest api I uh So it doesn't have to be inconsistent Because it wasn't regarding consistency if we have a well-ordered log then At least semantically equivalent code will be can could produce consistent results off of it Yeah, this because the one thing that wasn't clear to me when you described it It was whether you were suggesting that We offer up a log or a stream event type of thing In addition to what we see here or not or whether you're suggesting, you know what We only have the logs and And and then there really wouldn't be a way to say just give me the latest snapshot Which is what I think the the rest apis as I proposed here offers up So I wasn't sure whether you were suggesting an alternative or a mixture of the two The way that feels compact to say that is fairly indelicate. Um A lot of a lot of the engineers that I've worked with would struggle to really work with a a log driven Conception of the history of a service that's that's more in depth. There's more to know to do that But a materialization is easy for them And and it comes up with consistency problems and other issues like that. So I would think that Kind of the log would form the core of it and some specialized code would know how to materialize that and then Those that are more interested in just the latest snapshot Or don't want to do any of the extra work which for great business reasons or whatever can just access that materialization But that's that's an implementation detail, right? Because because you Because you can just go and create those the event stream From the projection if you want to so if you just want to go and store all this in a relations database It's it's actually fairly easy to go and create The the the events you need from the query Right, but I think I I think I agree that there's a lot of implementation detail in terms of the relationship between these two worlds But I think what I'm hearing from Eric is it will be nice if the spec offered up both Views or both worlds was everybody you want to call it and I agree that because we need to have we need to have a way to communicate um, the the event view um over the wire As cloud events, of course, and so um, that's that we need to go and express that of course Of course, there is no other way because we're just inventing the thing so we should go and use the thing Scott your hands up I think I have enough time for Next week. I would like to demo exactly what clements just asked about where Each of that the services in the demo produced cloud events when their catalog changes So that was like phase four of my prototyping that I've been doing I just didn't have time to get to it, but maybe I can get to it this week and show it off next week Sounds good to me Okay, so to try to wrap this up. I think uh, jem was going to open up an issue around Deletes, I think Eric you were going to open up an issue around the the the logging interface thingy Sound good so far Okay, and so back to the pr itself As I said, I don't want to merge it today. I think you'll need time to read through it But from a high little conceptual point of view Does the direction seem okay so far? Okay, not hearing any complaints. So please just review review the review it then for wordsmithing or whatever And we'll see we can get this thing in next week All right Thank you everybody Okay, so Let me between these two I know they're both relatively new but jem Do you have an update on the protobuf stuff that you want to talk about today or should we punt until next week? I wasn't sure there's status of that. Um, actually, I think we're pretty much done So, uh, that that's a late breaking update there was some concern From one of the reviewers around some of the language in our overall spec to do with timestamps because he had concerns around you If if a publisher sends a timestamp in in one You know stringified format for instance, and it arrives at the other end Maybe without, you know, it gets changed from an offset basis to a utc Zulu time basis You know, was there an expectation that local offsets have been You know retained across transports or formats and having had a quick Chat with with uh clements. Yes, that that doesn't seem to be the that's not the expectation So it's really a question of whether I want to tweak the spec a little bit just to make that More it's it other than that I think we're basically done. I will I will ask for one more You know round of votes from from all the different people that have chimed in on that pr So one of the longest running prs. I think Did I know? Yep Okay, any questions or comments for jim? Otherwise, we'll leave it to people to review it offline All right, cool. Thank you very much jim and thank you for all the hard work you put into that. I know it's in the a big one Do you still want xml after this? Sure, right right up a soap interface too, please I'll add that to my list Well, yeah, we have to do the soap. Is it the binding or is it the mapping? I don't quite know the one after this was going to be g rpc actually. I think that's a Is that a transport binding? You're doing Proto buff proto buff is I think they go ahead and hand it's like g rpc is the transport and then proto buff is your Encoding for it. Okay. So that would that's going to be my next um six month pr. Yeah All right, cool All right. Thank you in that case the last one on the list is slinky. I think this was opened up just today Would you like to talk to this one? Yeah, so I tried to to draft Our socket protocol binding specification um, I I've tried to to take inspiration from The existing implementations we have in particular the sdk JavaScript as a very well made sample of sending JavaScript outstanding web sockets over JavaScript and What I did is that I just put these in the words so the two big things Of the spec is that You send events just inside the web socket message So one web socket message is one called event which she serialized with an event format And in order to agree on the event format, we use the sub protocols feature of web sockets. So Maybe maybe open the the rythm. Uh, where I have a Example this one And no, no, no, I have in the not really a file's changed. Oh, sorry file's changed Yeah, uh down down. Where is the example? Okay, this one. So this is the example and shakes. This is a Normal and shake of web socket. So the client does a get request and add the upgrade What socket and The server applies with a reconnection upgrade. So the only thing that we Adhere is that web socket allows you to say Allows the client to specify what protocols it can understand So in this case, I coded our event formats to to somewhere to to the web socket sub protocols and The server when it replies says, okay, I've chosen this sub protocol Which in this case is json called events That means that during all the stream the events will be sent always as json So using the json even format And that's all the spec basically Then it's just words and formalities Oh Any questions for slinky? comments you came off mute I'm not sure whether I like this where I like the the the content type Being put into the or the format being put into the protocol Take about here well The alternative to that is that So we have two alternatives basically This is one of the alternative. The other alternative is that we define We basically encode this information in the path. So like you do slash events plus json To get events as json Yeah, but to be honest, I prefer this one because you have the choice So for example in this case if the server doesn't support json I'm just Seeing it could reply with abro because the client gave the choice use json or use abro Okay, I'll think about this I can hear the the wheel is grinding. Okay. Yeah. Yeah. Yeah, I mean, yeah, exactly. They're grinding Something something something rubs me the wrong way about this, but I can't articulate what rubs me the wrong way about this So I have to stare at this at this that I might also be in the end be okay with it. So I'm not sure yet where that but it's It putting putting the putting what effectively is the content type of the the the cloud events kind of baking that into the protocol identifier That's kind of what is like a jumps in my eye and says So so I'll I'll consider it and then I'll Give comments on it. I don't think it's necessarily wrong. It's just that I think I think you should look at it from from another point of view so In this context We are talking about a full duplex stream Where in both in both ways you send cloud events, right? Yeah, so the protocol here is How do you send the cloud event? And this how it's that how you serialize The cloud event to send it to me. So and if you think about that that Then this is kind of the protocol that the sub protocol, which is the name that I think I think what's what's um I think what what is um What's poking me is that If we introduce message pack or seabor if when Then um, we'll have to go and update that spec Well, uh, well, well, well, wait, wait, so I think It's fine to just use the um the other content types So we could I think we could use applications slash called events plus jason. I think we can do that Uh, the reason why I use this Notation so jason dot cloud events Is just to follow the guidelines of the spec But I mean we can bend those guidelines and use Our content types so we don't have to update this I think there are some that there is a bit more to negotiation in in in the web sockets in web socket so so um I think we understand each other um So my I think my concern balls down to I would like for the bindings for these binding specs to be stable while we add more encodings If possible right with jason being the weird exception because that's the universal stuff that everybody's is doing but um, otherwise I would like for us to be able to add seabor and not touch any of the any of the the specs to be You know for special enumes, etc Well, then we can just say applications slash cloud events plus seabor and that's fine too, I think Yeah, so Okay, well, I mean your choice. That's something that debatable. It's it's in the end. We're all going to agree on it um But just that was my reaction to it's like this is a little I'm always thinking about the the sensibility angle and stability of the specs angle when we um are making this composable so that's the So that's my I think that's ultimately my concern. Let's let's think about let's think about how we can go make this a little bit more flexible Okay, any other questions or comments? Does it seem like a the right general direction to go? Aside from this question Okay, not hearing anything. So please when you get a chance to review this one All right. Oh, I I have something to add. Yeah, please go ahead. Is that uh, so Maybe we need some input here. I don't know So The there is this corner case, which is not Very specified by by the web socket spec. So In case the server doesn't support any of the protocols the client asked for So for example, let's say that server doesn't support nor Jason nor Avro Uh, the response should not contain the protocol header But it's not really specified What should happen that so what I wrote in the spec is that the client Should close the connection The client the server The client the client should close the connection because it receives an upgrade Without the protocol. So it should close the connection. Ah, gotcha I I think refusing is refusing the upgrade not specified Sorry, I think I think I think there's I think that's that's that's actually defined to refuse the upgrade It's not defined what happens when uh, when the protocol is not uh, when you don't support any of the sub protocols Then you just don't you just don't accept the socket You know, which means which means you can it's your choice. Whether that's your whether you choose to be that your your fault or the client's fault But then I think the right answer is to to give back a 400 Or not supported Well, but that's uh, yeah, what I'm trying to say is that This exact point is not defined by the spec. It just tells you a you should reply Without any protocol header and then it's that there's nothing else. So yeah, if you can just look at this particular But since you're an htp Closing the connection is none of your business is none of your business at that abstraction Layer Right. You simply refuse you simply refuse to to honor the upgrade request and that's it But the client is then completely at liberty to reuse the connection for to do something else Yeah, I What I mean with close the connection in this context is close the web socket connection maybe Yeah, but you're not you haven't established one yet But you're doing you're you're you're you're doing a polite Applied request. Yeah, this is for an upgrade and that upgrade gets refused by the server giving you a 405 or 400 and then the connection just sits there waits for the next thing that you want to go and try but there's no need or There's no need to close the connection because you you might then go back to go and and and try something else And and that will reuse you have no effectively in in most htp stacks. You don't even have control over the socket at the bottom So I know what you mean. I'm just saying that formally what you're writing here is wrong Okay, okay. That's what I wanted. That's that's that's like Yes, you should walk away. That's basically what you're saying, but closing the connection is formally incorrect. Yeah, yeah Yeah, let me fix it All right, cool. Anything else you want to mention slinky? I'm lowering lowering these things We're here for Slinky anything else you want to point out for people to Pay attention to No, no, just look at it. Yeah, okay. Cool. All right. Any last questions for him before I move on All right. Thank you. I think that's the end of the list So are there any other topics people wanted to bring up? All right in that case before we switch over to the sdk part of the call. Let me just do um attendance You quinn, I apologize if I'm butchering the name you quinn. Are you there? I think they may have just dropped lance you there Yep, I'm here. Okay. John. I think it's john dropped off. I don't know which john it was though, unfortunately It might have been Mitchell. Uh, matthews you there? Yes, all right and daniel Here and paris Paris I'm here. Um, excellent Welcome Okay Did I miss anybody for the roll call? Okay, and actually hold on Do we have anything on the agenda for today? We have nothing as right now Does anybody have any topic that you'd like to talk about otherwise we could just end both calls right here Right now Okay, yeah, cool I don't I don't think anybody's going to complain to get any more time back Okay Not hearing anything. I'll make a note in here that we canceled the call better than that Thank you everybody Do we have a timeline on when we're trying to make a cut of the discovery Registry and subscription apis Uh, I don't think we've decided on one yet Should we talk about a timeline next call? That would be a good idea. What is our well Release events or those things are what do they mean anything anymore? I don't know Yeah, we should talk about that next week. Okay, sounds good. Yep. Okay Cool I like the idea of putting a target date in there. I like I like forcing functions. So that'd be good Thank you Scott for mentioning that good. We used we used to have events and in-person gatherings for those things But now time means nothing Yeah, we should release this. I think let's let's target like march Uh 150 Oh, man, aren't we already passed that aren't we at large march 200? Oh, I don't know That's what I mean Oh my god, we're going to a rattle here All right, anything else Otherwise, we're gonna we're gonna end this call and not have the stk call any objection fabulous All right, and that gets we are done. Thank you everybody. We'll talk again next week. Bye. Have a good one. Bye Bye