 Hey everybody I'm sorry I'm running late. Give me a sec just to get myself organized here. Let's go to the last Christian Hey Doug, I'm here. Hello Eric Good morning. Hello John Good morning And oh look I'm here. Hello ginger. I'm here. Sorry. Good morning It's a rough morning already. Tell me about it. You're not believe any phone calls. I've had all right Nick Hello I lost myself Remy Hey guys. Hello Brian are you there? Brian young. Yeah, as soon as I can figure out how to unmute. It's always the challenge. Yes another person has problems with mute Scott are you there? Yes, and Francesca Hello, hello Tommy Hello, Vinay Hey Doug. Good morning. Good morning Vishnu. Are you there? I could spell Vishnu Vishnu. Are you there? All right, what about Vlad? I'm here. Hey, hello. Hey, it's been a while. How's it? How you doing? Fine fine quarantine All right, Mark are you there mark Fisher? Yes, I am here. Hello. All right, Mike. Are you there? Present present so official. I love it Lance Yes, I'm here. All right. I miss anybody. How about Vishnu? Are you there yet? All right. I'm all caught up. I miss anybody No, we're gonna miss quite a few people today Because of vacation in Europe. All right. Give another minute or something. Let's try it That's our way doing today Hanging in there So ginger you're in the West Coast, right? No, I'm in Austin How are you guys doing in terms of like opening back up? Just curious It depends on what opinion you would like I'm not asking what that's going well. They're good. I'm just curious. Are they starting to look it up at all? Oh, yes Austin opened did a partial open two weeks ago and then every week they open new stuff Regretfully in my opinion Tomorrow they open everything so all bars tattoo parlors massage places like all that High population close contact stuff will be opening so interesting Interesting. Okay. Yeah, I think we're I think we're a little slower here in North Carolina So be interested to see how it plays out. I'd prefer to be slower. So I'm just gonna stay home probably for the rest of my life That is an option is we're lucky that in our in our line of work We can work from home if our company lets us so that's that's good. All right, it's it's oh, it's four after we're way behind Sorry for that diversion. All right. Um All right Nothing for a eyes. Okay community time anything from the community people want to bring up All right not hearing anything Sure, should I say here but later in the SDK I'm gonna do a quick demo of SDK rest somebody's interest. Yep So if you're interested in the rest demo join that first five minutes, but it should be interesting. So If you're interested, please join All right So the SIG update this is interesting so I think last week I mentioned that The TOC seemed like they were more in favor of us creating a SIG as opposed to just being a workgroup under SIG app delivery Unfortunately, I'm starting to get the sense now that maybe that's not true or at least one of the people On the TOC definitely does not think we should go that path. They want us to remain a working group so I basically said we don't care. Whatever you guys want. Just let us know because I don't want to get into an endless wordsmithing to try to define Serverless so that it differentiates us enough from SIG app delivery because in my opinion, it's all the same thing So we're gonna let them decide and I don't know what their decision is yet I'm gonna lean on the TOC to make that decision for us. We just don't give a crap to be blunt about it So it's still up in the air. Just let you guys know All right moving forward though There is an SDK call after this one if we end early, we will start that early. So be prepared for that Let's see, I don't see team were on the call So I don't think there's anything to update there other than keep in mind They do have a their own repo now I did manage to convince the powers that be to give the workflow group their own repo so that they can move their stuff out of the serverless Get a repo because they felt a little bit like they were being short changed by being just a folder under that repo And they wanted to be they wanted to be able to advertise themselves a little bit more and point to a folder Wasn't quite as nice as a full-blown repo So I did manage to get them a repo and they are still trying to figure out the process for becoming a sandbox project And we'll see how that plays out, but I think that's the only thing worth mentioning going on there Any questions about anything we've talked about up till now? okay now it was noticed that the master or head versions of our documentation I'll save v1.0 and While a lot of them haven't changed for some things they actually have and that's a little misleading because technically they're in The process of being coming maybe a version 1.0 1 at some point But whatever the whatever their thing is It's not technically 1.0. So we should probably name them something different at the head level In the past we've named it v whatever the next version is going to be dash rc1 Just to make it clear that it's not it's a candidate. It's not official. It's just a work in progress So I was thinking of doing the same thing here and for now calling it v 0.1 dash rc1 We could also use dash wip meaning work in progress I don't have a strong preference, but I figured I need to get input from you guys to see whether you care one way or the other Anybody on the call have a preference for which way we go in terms of this, but I do think we need to name it something Rc has a Pretty distinct meaning in it. You can basically means you're this is pretty much a release unless you find something It will fix it before the actual release. So So in other words, what I'm saying is a work in progress and our C are to write into different things So it sounds like you're leaning a little towards more more towards wip, right? That would be based on your description. That would be my opinion Okay, shouldn't we use 1.x because you don't know if it's gonna be minor patch or That's a good point too. Okay. Anybody else want to chime in? Thank you Vlad for the plus one. I Agree with both of those points. Okay. Anybody have any other alternative they want us to consider? Okay, I'm gonna make it a formal Ask then is there any objection then to Ending. Oh, sorry, Lloyd. Sorry. I probably misspoke like one point x not one point zero point x correct Sorry, I did miss to that. Okay. Thank you. All right. Any objection then to heading down that path? Okay Thank you Perfect. All right Um, all right before we jump into PRs and issues Is there any other topic that we need to bring up? Okay, just want to make sure we're not going to run out of time. All right. So as promised Clemens sent in his proposal for the schema registry and I see oh good. There are just some comments in there I haven't had a chance to look at it myself, but he did his duty promised Now because he just sent this in yesterday Uh, it's too soon for us to officially vote on whether we merge it or not Um, and unfortunately with him not being on the call. He's not here to take any questions Um, but for posterity in the recording anybody have any comments or questions that maybe someone else in the group might build answer Can you paste the link on the check window? So yes, I can There you go. Okay And as I said, obviously we don't need to do anything with it right now This is I'm just bringing this up more for you guys fyi so that everybody can take a look at it Then hopefully the next week's call will either discuss it or Vote to approve it as a you know working draft that should be merged and people can then do prs and issues against Okay any comments commentary All right moving forward then Okay, um Tell you what let me do this gems. I just noticed you joined the call Since we can't vote on this since you just added yesterday. Let me give you a chance just to introduce this issue Or a pr I should say Just so people are aware of it think and review it for next week You know, this is one of the dangers. I guess I'm sitting at home twiddling my thumbs and wondering what to do So I you know, we had the proto buff or a proto buff Suggestion and we yanked it just before v1. I can't remember exactly why we did that But it got yanked And as I hadn't seen anything coming back I thought I would take a cracker creating, you know a version of that I've I've basically taken an approach. I don't know if you want to go to the the schema file Um, uh, it sort of fully encapsulates um a proto buff representation of a cloud event So it allows for, you know, a set of attributes And then a distinct You know payload one of those payloads could be a proto buff object itself, you know, so much like In jason you allow the The body to be a jason document This allows it to transport a pros of our objects as if they wanted I took the approach of Defining the attributes in terms of you know, the cloud event Attribute types or our type system So using this model, I believe we can carry or represent any Yo type that You know that we want within our type system The only thing I haven't done And this was I think what I'm looking for Guidance is I took the stance of of just defining all the attributes as a map Rather than calling out individual property fields for Like the spec version and the type those sort of required fields I'm I'm still mentally on the fence to be honest as to whether You know, this is a simpler model or a more complex model But I was really putting it up there for for comment Okay, uh Francesca your hands up Yeah, so I'll tell to you that I have a really really little knowledge on protocol but What I see here that I don't understand honestly And again, that could be because of my little knowledge about protocol is why you did one off on the data I mean, this was I think in even format in the jason even format This was originally down to make easier to read the code event when when it when it's sent in structured mode But in that case you already send the protocol as a binary. So Or what is the reason behind doing data one off? So you mean a one-off in terms is it a byte stream? Yeah, I mean you can just send yes What I mean is that you can just send you can just say that data is just bytes and that's all Right, but I mean much like I guess my argument would be in jason We allow a jason object to be natively inside the data payload. Yeah so Certainly from a protobuf perspective I can just natively put a proto object in the payload as well. Yeah, I don't need to You know try and hide it inside a byte string. I can just natively represent it I Part of this is actually come I had some pushback internally in the company over our usage in especially in the jason format of having a You know a string payload and a base 64 encoded string payload. Yeah And a lot of people coming to me saying well, why is that? You know the the content type tells you what's in the string. So why Why do we need to treat them differently? I also think if you if we represent bytes explicitly Then, you know, it's a protobuf marshalling as to how those get Put on the wire It's I don't have to do any application Encoding, you know, it's just a buffer. I just stick it on there. We don't really care Yeah, I don't have to encode that byte string those bytes into a string to be able to carry them I can't remember how the avro Addressed this I I must admit. I haven't looked at the avro spec I I don't know if that if avro allows you to carry Raw raw bytes But that was my thinking. Yeah, if it's a binary payload I could just pass it as a binary payload Okay, any other quick questions for jem? Okay, let me just notice with the lack of questions Well, let me let me poke the google guys for a minute. I don't know. I don't know the all the mechanics But just based on my recollection from five years ago There's absolutely no issues with encoding binary objects within avro We've done it. I just can't remember the mechanics Well, let me tell you what I was going to say though that I know we have some google folks on the call and so if you guys can maybe poke some Protobuf experts within the company to take a look at this I'd love to get their opinions on it. I I already picked evan anderson's. I know he was One of the first folks I said, no, he didn't create the original when we had but he was definitely Looking at the one we had a long time ago And I think he had been the one that suggested we drop it because it wasn't It wasn't quite right So I did poke him to take a look at it. But if there are other google folks who Who know of experts in this area, we'd love to get their feedback. Yeah, as I said, I mean I I sat on the fence with using the one-off construct. I know, you know, it does Introduce a little bit of a performance impact But on the flip side, it makes it very explicit about what you're passing around. Yeah Okay Uh, Vinay your hands up So I had a question around the context and the consumption, right? Uh What I mean by that is obviously when you're using Protobufs to serialize you need DC realization capabilities, how does that handshake happen? How is that expected? Is that a type? Of encoding or something like that. Is that and that's not clear to me from this Pull request maybe just adding a little bit more context around it will also be really helpful As we think about this. So so you mean the notion of how I would transport, you know A serialized, you know A protobuf cloud event over HTTP in structured form. Is that what you're referring to? That's not the question. I think the question is as a sender Let's say I choose to use protobuf and I serialize it and I send it out and as a consumer How do I know that it is I need to it's it's a protobuf serialization and use the consequent deserialization capabilities as opposed to abro or json Ah, okay, so that would be in the the content in the transport It would use a I think you just was past it. Okay. Where is it? So yeah, the transport layer so much like in the jason format you say if it's a structured payload then we say cloud events plus jason So here, you know If you're using htp for instance, then the content type would be would be what's shown on the screen there So that's how your My understanding from a cloud event perspective is that how that's how we differentiate it's a Structured event because it it's application slash cloud events Plus, yeah, and then the actual Encoding or content type is what follows after that. So that's what we do for jason. I assume we do the same for avro Got it. Thank you so much in my bed. I missed that. No, no, it's okay All right, any other questions? All right, cool. Thank you gem and just a reminder Please review it during the week so we can try to possibly vote on it next week. Um Have you seen any issues? Please open up comments in the pr So this is all I know I you know, I've not tried end to end sort of sending stuff around I do you want me? I don't want it to be a purely theoretical Right up. Do you want some evidence? I can actually make it work That would always be good. Yes, if you could test it Yeah, testing will be good. Okay. Yeah um to be honest though, I At least maybe it's a wish more than anything else. I would assume that um Once the pr gets merged and it's out there I I can't imagine our stk folks wouldn't look to pick it up and try playing with it too Right, but I think some initial testing from your side would be really good. I would assume all right okay Oh today your hands up again Sorry, uh, one more question dagas. I've been part of this team now for like two months I'm just wondering as we start supporting newer encoding schemes, etc What kind of uh out of the box testing capabilities do we have that we can do You know quickly test these kinds of things run these quick tests and so on Is there something that's readily available or it should be start thinking about having that kind of capability So I'm not sure we have a whole lot now beyond what the stk's offer But I'm going to poke on scott here for a sec because I know scott has done a lot of thinking around Conformance test suites and something not necessarily 100 percent related to what you're asking But I think it kind of touches on it a little Um, but I think that's probably the closest thing we have sort of in the works scott. You want to comment a little on that Honestly, it's like he's been doing most of the performance testing. Okay. I've been doing conformance testing Which is different. Yeah So I think if you vene, I think if you want more detail about what they've been looking at I think you might need to reach out to those two guys But uh, sorry, can you repeat their names? Yes scott scott nickles from vmware and then uh, slinky or francesco From red hat We also have a new cucumber set up With uh, some pre canned cucumber tests and then there's some light integration that happens for stk's I'll take a look at it. Thank you Yeah, cool All right. Thank you everybody All right. All right moving forward um Let's see. So this one I think is the only other pr that's out there that's discussable um So since last time we talked I thank you vene. There's a link in the chat from scott if you want to go with performance stuff um since the last time we talked, I think the only real change I may have made is Fudge, I think I forgot to push I thought I changed this from service to Something different. I forgot to push it darn it um I try to remember what I made it Mike do you know The text editor there is that undo button Yeah That's I hate it when I do stupid stuff I even thought I made a comment in here whatever changed it too Oh, no, wait, no I don't know if I apologize. Hold on a minute. Let me see if I can find my code No And no actually in my code it says service. What was I thinking? Oh, no, no, I'm sorry I was mixing up source and service. No, I changed it used to be source class and then I changed it to service I apologize gosh getting old stinks Where is it? Okay, yeah, so in the previous version of this, I think I had A source class or something like that and then I changed it to service because I thought that might be Um a better representation of the abstract concept of this thing That's going to be generating potentially lots of different events for lots of different sources I don't know whether service is good enough or whether it's overloaded because everything out there's a service these days But that's that's my initial that was my initial take on trying to fix the problem of people not liking the word service class I'm sorry source class Anybody have any thoughts on that? Okay, we didn't discuss it last time didn't we? we Sorry, I know I know we talked a little bit about it. I don't know where we landed But I think we did talk a little bit about it. I think we landed on the fact that source class was not the right word I Let's see anything. Yeah, it's for me service is good Okay, so the main so there's to me there's two different parts of this pr There's one which is you know, sort of adding the the text up here the pseudo yaml type stuff There's a little bit of wordsmithing That's one piece and obviously a big part of that is the word service and services. Um as opposed to What was it called before? Start with a p producer provider one of those right then the then the second part is The examples that talk about how to do queries and that's this thing down here And what I'd like to do is I guess split the discussion into two first Is there any concern about the the first part the wordsmithing the use of service and nothing set in stone So we can change it later, but I'd like to first focus on the the wordsmithing part more than anything else And then we'll talk about the query part second. So scott your hands up Yeah, I was just implementing the abuse protection for webbooks and I wonder if we could kind of leverage some of that terminology with origin What do people think Well, my my only concern with the word origin is When I hear the word it almost sounds like the the the original endpoint that sent out the event It doesn't necessarily convey this notion of A bigger piece of componentry that can have many different event sources under the covers origin sounds like a singular kind of a thing to me Well, origin is point to point. It's the in the context of the a live request, right? Right, but I at least to me anyway, I think The the entity that goes here is bigger than just a single Single thing, right? It's it's it's almost like the the global app. No, it's like if it's an object store, right? It's like or github. Let's pick on github. It github is a service. It's not. I don't think even to say as a origin per se City producer Well, see then we get back to the problem we had before we're producer and provider are too close together They were going to mix the two up Yeah This Doug, I mean if you take the service mesh example, right? You have like A container in a pod and then you also have a proxy for example And then the proxy is sending stuff on behalf So maybe my suggestion was to try to distinguish from given our discussion from last time How about originator to actually distinguish and identify the the entity that was sending Originated literally originated the event and then the to to identify the proxy Which is that bigger system if you will that you describe to call that the source um Well, you it's almost sounds like you're trying to redefine source which we can't redefine Because sources defined by cloud events. So we can't touch that Um, I'm trying to figure out how to get out of this rat hole To be honest what origin can have many different sources, right? Origin originator we're kind of dancing around almost the same topic So I I'm I'm plus one for origin so if we If we use origin on line 127 that I've highlighted What would be the plural? Origins is that sound right to people to people? to people I guess I'm I'm just struggling and I and I admit it's a it's a personal preference kind of thing. I just When I hear the word origin, I don't think github Right, yeah All the way with you Yeah, and that's that's what I'm kind of struggling with is because Ordinance to me is a very is more of a lower level geeky terms like the origin of this message, right? And I'm we're trying to convey something bigger That's at least to me. Anyway a little more user friendly that says Hey, if you're trying to map these things to concept to understand Github maps to what? Origin doesn't jump out of me service does Yeah, it's like I should be able to explain to my wife. There you go I don't know What if we do this I because Nothing is set in stone. We can change these things later Is service horrible while people think about whether Origin or something else would be better I'm just trying to get away from the the p-word because the p-word we're having there right now I think it's incredibly confusing I'll just about to suggest prominence, but that's another Thank you just to make it more fun mic your hands up. Yeah, so I I Service is potentially the right word Service is perhaps the most overloaded term in in cloud computing Uh, so like that would be my only caution against that um I think I personally think that source is the right word, but I you know I threw that bomb out last week, but I think cloud events to find service wrongs or source wrongs, so Um, you know, I think where we're left with is service is reasonable and I would encourage folks to rather than bike shedding on the name to think about The people that are going to utilize this and the environment with which they're going to use it and if a user is selecting a Kind of think another word, uh, you know, they're selecting where they want events from They're gonna they're gonna think about the list of service providers or services or You know, anyway service is fine, uh, but think about it in that context like let's not get too Weird on the name Yeah, I agree with everything you you said there and I think thank you for speaking up. Mike's since you Put put together the first draft here. I was going to poke on you to see whether you Live with wrestling with this problem. So I I'm I'm over here laughing when the mute button is on I'm sure you are And I keep in mind I'll get to you. Vinay in a sec. Just just keep in mind folks We are not looking for the perfect word at this point in time We are looking to make forward progress And I and to me getting away from the p word is forward progress at this point in time Not that service is going to be set in stone just incremental progress is all I'm looking for Vinay I'll just add to the jokes anyway and The g word how about a gender service is very very generic right everything is a service as has been commented on But generator how about a generator because as a consumer? I mean, I think that's the context that I'm always trying to address these things I really don't care about the name But I need the context and how about a generator I need to know I want to subscribe to these This class of generators or a generator or generating service. Does that make sense? Anybody want to chime in on that one So it's a very Python Python is the egg again generators also Has a I especially encoding has a very distinct meaning because there's a lot of code generators which Could create a source of confusion Again personal preference. I'm I I'm not enamored with generator just because I would not know what it meant One option maybe in the same vein would be But but less implication of of being the actual generator would be emitter The problem I have with generator as well as origin is that they both imply that it's it's the thing that created the event as opposed to It could be that it's just a transport passing an event through So any of those verbs that sound More active maybe maybe don't fit as well Okay, I'm gonna do this Trying to get out of the rattle again What if we do this and I know it's this suggestion is obviously very biased because it's my pr um Could we accept source now? I'm sorry Not source. Can we accept service now? And then I will open an issue to start gathering alternatives and we can hash through an issue and not Take up time on this call and then you can throw all these wonderful Joke or not joke names into the issue And we'll revisit this Anybody object to that Okay, so back to my other question in general Everybody okay with the wordsmithing and changes I made aside from The name of service Okay, what I'd then like to do is jump down to the other thing Okay, so, you know what would help when you do create that extra issue You could uh, that little comment that you have what it is like when you get it to fire, blah, blah, blah You could probably elaborate more as to what it is what it will do what it's supposed to do So I'm sort of for just free end and then Be easier to The I just want to make sure I understand what you're asking You're asking me just to make sure that I have a clear definition of what is the entity that we're trying to name and what its purpose in life is Yeah, like we We back in the days had this sort of thing where we would say name this class and we would just say Explain what we wanted to do and then people come up with an idea is what the proper name for the class For example, so it's the same kind of idea. Okay, or you can basically provide maybe more detail is as to what Yeah, and to be honest, I don't know whether I did a good or bad job I did try to define service up here Um, whether that's like I said, whether it's right or wrong don't know But that's what I would tend to do But I would definitely if nothing else at least paste this text into the issue and if people want to wordsmith that as well Go for it Okay Um The other thing that I wanted to focus on as part of this pr Is I did start getting a little bit of an alternative way to do queries Because I know mike had something in his original proposal and I have some concerns about that and I think we talked a little bit about this in the Actually, I think in this pair itself where I think mike your proposal if I can find it or show an example Let me do this See if I can find some examples Well, I mean the big thing is I was starting starting like thinking about the entry point and starting from from both ends So there's this there's a scenario of I want to view a list of services right that I might want events from or Man, I got the event types that I want I want, you know come that example dot storage Where can I get that from? And if we don't think that second entry point is a valid use case then much of what I specified or part of what I specified Could be dropped Yeah, I think I think the way you phrase that is probably the right way to sort of phrase the question for the group right so um actually Yeah, so Okay, let me Let me go back over here. Just try to frame the the conversation better So I think one of the questions for the group is Do do do do and the other thing I put in the comments was that this this is why graph ql Actually lends itself really nicely to this problem because it doesn't require us to prescribe the entry point But let the consumer of the information Ask for exactly what they want yeah right, so to elaborate a little on What mike and I are talking about here is If you wanted to search for services that have certain properties Would you expect to type? services slash and then the service name And then potentially other query parameters that further qualify That service because you're serving but you're the main point here is you're searching for the service by name Or if you wanted to search for things by types, would you do you know slash types slash whatever? That's one alternative Right, so basically service and types can become top level entities Or would people prefer Where is it Something like this where everything is specified as query parameters. So service equals whatever you're searching for type equals whatever you're searching for Because I think I think both are probably technically valid Um, let me go ahead and state my biased opinion first I kind of prefer this because I think this gives us more flexibility Especially if we're going to eventually be searching on other things like protocol and stuff Whereas it's not clear to me Whether this format over here means you now need to have a top level And a top level word for every possible thing you're going to search for because that's the thing that people care most about Whereas this says we don't care what you what you as a user think is most important. Everything is just a query parameter But Mike, maybe you want to chime in or maybe not Maybe not Okay, I just noticed you're off mute. So I was going to pick on you I forgot to mute Okay Anybody want to chime in in terms of a preference Because what I could do is say well Pull this out of the pr and only talk about the wordsmithing stuff first and leave this for a second pr That's another option as well. I was going to offer that as a sort of compromise to worry to split the two Jim your hands up You can't run wondering if that would be a viable approach. I think that would be an incremental Change for you, which I think you you would appreciate um I I guess my my concern I I'm I'm still sort of On the graph ql side of the fence to a certain extent but The trouble with some of these is that they're completely unbounded. Yeah, so As soon as you go down this road, you need to include pagination and a whole bunch of other stuff. Yeah, because I may not have any idea what what services you offer or what events are available and that list could be extremely big and Also, I guess you need to account for regexing. Yeah, so I might know that com.example Is an event family, but I don't know any of the types underneath that um So I don't have a good answer to this but I I think it's I think it's a kind of worms But also I did put a link in and we've used rsql which is like a version of fickle For some of this sort of restful query stuff. Um, I don't think it would address your You know, what's the root of the query? Yeah, but it it does sort of formalize doing equals and not equals and ins and not ins and and stuff like that. So you you do get quite a rich sort of query semantic out of that so Yeah, I'm not I was hoping to necessarily I was hoping to kind of avoid as you said the the can of worms with the full Full with the full set of things that we might want to include as part of our query language If you want to call it a query language, right? Um, because I'm not convinced yet whether we want to support everything you mentioned or we want to keep it really simple And say no, we're going to keep it simple If you want to do something more more advanced then we have this Graphql thing as a as an as an optional layer that sits on top, right? I wasn't sure where we wanted to go with that yet um, but it seems to me that When you start to think about doing anything beyond the most basic thing of simple word searching It seems to me that using query parameters gives you the most flexibility doesn't it right because I I'm not quite sure how to Do it this way without Without feeling like we're sort of bastardizing things I mean that's a common use of rest paths, right is to include In a way these are sub resources Right these the specific event types that a service Provides are a sub resource Uh, so like the the line of the box above where your cursor on is is certainly how I think about it Yeah, and I definitely agree with you if I knew exactly what I was working for This is exactly what I would type to traverse the tree totally agree with you Right, but if you if you stop short like if you do example dot com slash services You should get a list of all the services And then you know slash bob service slash types. You should get a list of all the types True, I guess the question I would have then is okay if you do example dot com slash protocols Should I see a list of all the protocols that are supported across? Something I don't know In typical rest the service would be singular because you've picked blob service and types would be singular Because you've picked com example widget So this would example dot com service blobs blob service type com example widget And the types is the the way you know how to make a query Yeah, good catch that yeah, that's a good point too. Okay. I apologize. I forgot to see the hands up So john your hand is up first Yeah, well, I'm gonna say I think what mike was was talking about I think I think part of the issue here is You know, what are what are we trying to do? right, I mean the notion of The core notion of rest is the is the discoverability Right, which I think scott and mike were both just talking about If we're just if we're just trying to create an endpoint over h d up where we want to allow just You know completely random Um access to the core data. I think that's where the the camp that says we should just go to Straight graph ql. I think that's part of where they're coming from right so so it's sort of at least in my mind in this discussion the question is Are we are we trying to Put structure into this right to whatever degree of generality. We're trying to get on the querying side But I mean rest has a notion of I mean it is a model, right? We're creating a model of these these restful Objects if you will versus here's a sea of data have have at it, right? And I think that's the more fundamental I don't know existential question here So let me they poke on you a little there john to elaborate because I think everything you said makes a lot of sense But when you in particular the end there you start talking about a model and I definitely agree with that Would this type of line then violate that model because the model Probably starts with services up top not types Do you think this is violates that model or do you think it's still consistent? Okay, so I'll put on my restefarian hat To answer that so one of the one of the problems that people have in in over over now decades with rest is They think modeling means there's a single fixed Model right with a single hierarchy that's that it's better to think of those What you're calling the top level things Uh in database terms think of it more like materialized views Right. So so you can have multiple different materialized views into your same data, right? That you come at it be a different dimensionality Is is more of how I think of that. Okay fair enough I can then the follow-on question I have then is Would that mean that it would be our responsibility as spec authors to define A fixed list of views upfront or should they be able to put pretty much any property as a top level thing? So then that goes back to the rest versus Graphql in my in my mind I would suggest starting off with You know, whatever some core small set of obvious dimensions and and see how limiting or Not limiting that is to people And like you you mentioned earlier in this discussion I mean, you know, if if we're going to do this thing where we say, hey, here's this base Uh base approach and if you need the full Generality, we built this Whatever whether it's optional or not Graphql Chunk on top that you can use if you want to you know do something Not part of this core set. I I actually kind of like that idea because the The passion of the graphql community Uh in this call has made me spend more time with graphql And and I and I see that point Okay, cool. Thank you. Thanks for thanks for elaborating and let me poke on you gem your hands up Yeah, I I think that's a good approach. Yeah, and and then you would say, you know List me all the services and then you'd have a filter on that for the protocol I mean and I think that's probably the way to approach that is just try and pin on a couple of Roots and go from there and not try and Not try and put a dimension in for every Potential thing you might want to filter or sort on. Yeah, okay. Okay. Okay. No, it makes a lot of sense I think there are a couple of Concrete views that we should be prescriptive about and and that's sort of what I did in the original one Uh, we want to promote interoperability, right? So we should think about what we think the minimum set is Yep, okay all right So I'm definitely hearing from the group that I should move the second part of the pr Which is the query stuff and focus just on the wordsmithing and Provider to service switch Any just any counter review to that any or any objections to heading down that path? Okay, I will make those changes um Given we are nowhere near one point though Do you guys are you guys comfortable with me making that change of ripping out that second part of the pr And then merging it or do you want to wait until next week for another round of reviews? It would strictly be removing stuff. I would not be adding anything You're pretty shifty. I don't know Well, that's what I was trying to figure out what you guys trust me or not If or if you feel more comfortable what we can do is this I will make the changes today And then give you guys until end of day Friday Before I even think about merging has that or I can wait. I honestly don't care It's not like this is that urgent I'm just trying to make some forward progress here because I know we've gone several weeks without any prs being merged Anybody have a preference? Okay, tell what I'll I want to be aggressive. So I'd like what I like to do is I'll make the changes I promise to get out there today and then I'll wait until Friday to let people have a quick review And then no objection by the end of Friday. I'll merge it or wait till Saturday morning or something Okay Thank you everybody. Um Okay, that was it Francesco, did you want to talk about this one or hold off still? I didn't see any changes That's what I thought. Okay. Are there any other topics for the Cloud event type specifications work Otherwise you might end early Okay, uh before we end let me do my favorite part of the meeting roll call Um, I did see Ryan talking to chats. I'm going to give him credit Uh, Vaklav, are you there? No. Yeah, Vaklav, are you there? Yeah, I'm here. Excellent. And Paul, are you there? Oh, Paul left. Okay. What about Vishnu? Okay, did I miss anybody on roll call? Okay, in that case if you're not interested in the stk work, uh, you feel free to drop and thank you everybody for joining And let's just give everybody like two minutes or so. Um, then we'll start up the stk call Okay I'll take some notes here Sorry, Francisco, but you knew it was coming. All right. Tell you what I'll give it till 52 on my clock. So hopefully less than a minute. I'll get started Hey, Paul, you're back Back and better than ever. Here you go. I'll give you credit Pow, baby All right, 52 on my clock. Let's get this puppy on the road. Okay. Um, fritisco, are you ready? Where do you need a little more time to compile? Yes. No Okay, let me stop sharing. I'll let you share. Yeah, luckily the completion cash Excellent so, so, so, okay, so, um I'm going to show you, uh, a demo, uh, which shows more or less the capabilities of an sdk rust So in this first release, we have, of course, most of the dpi's are considered unstable But we already have some interesting integration. So we have the basic create Creates and rusts are like modules Um, the basic create provides the event that the structure provides the jzone event format implementation And what really matters is that this module This create is tested with uh new libc Web assembly and moves the two chains And then we have I implemented the integration for to Widely use the Libraries of that octics web for creating web servers and the request for creating Our web clients So Do you see the code? Uh, yep Is it too small for people or do you need to make it bigger? And you just yeah, I think that's good It's okay if it's just me don't worry about it. I'm a little 13 inch mac but go for it. I just full screen it. Okay So, um, one demo It's this one and It's a demo that shows a web server. So you see on the right on the left screen The code of the server So this is uh the main of the application the main of the application is done with updates that provides an even loop implementation and I I have I have I have two path on one path. I just print the event and on the other path. I Reply back with an event The other part of the demo is this other example And this is a really interesting example because it it shows out the cloud event as decay can compile it to web assembly so This is the html of the page is just a form and This is the javascript of the page Which invokes The compile the web assembly module and then using some jQuery thing it invokes The web assembly module created with rust and the rust code Uh, basically when it's invoked, uh, it creates a new event using the event builder And then it sends the event using a request Which which cost compile to web assembly So Let's run it Yeah, because this one needs npm. So npm around server And on the other side start the server So this is not npm The application is ready and where we go to p80 Okay We see the form compile the forms to send the event to the target Make I add some mock data and I send when I do send On the other side, I see that I received the event and that's pretty much everything Any questions? Cool What I really want to underline here is that the module compiles with with assembly compiles with glibc and compiles with muslin for who doesn't know muslin muslin is a Micro implementation of libc and allows to create docker images of the size of 9 mega so, uh Web service Whatever created with this sdk is around is around 9 mega 10 mega It's cool Excellent Any questions? All right. Cool. Thank you very much And within five minutes perfect Yes All right, let me see if I can share something again, even though I don't think I'm going to stay here very long my screen Oh, there it is Okay. All right, uh quickly. Um Unfortunately, I don't see grant on the call and I was hoping that he would be but lance you're there But I was kind of hoping to get both anyway, so I know last time we talked Actually was the last time before we talked about, you know having type type script sdk versus java script sdk and and we needed both or something like that and um Since then there have been lots of conversations going on in the background And it seems like we may have come to a fairly good resolution where it or I think we're going to try to Work to support both type script and java script within the java script sdk And that's all goodness However, what wasn't a hundred percent clear to me was whether that meant we could Kill the type script sdk or whether it needed to stick around for For other reasons like maybe we weren't sure whether this this this merging is going to happen or whatnot Um, so I was going to ask on this week's call whether we could formally kill or not But obviously since Grant's on the call and he was the main proponent for the separate one I'm not sure we can make a formal decision um So what I'd like to propose is first to find out from the group on the call Whether they see any reason to keep the type script sdk around or not just to see whether Whether I'm misreading their tea leaves And then I will if you guys do agree that we should get rid of it um I will then reach out to Grant and get his perspective on it And if for some reason he thinks we need to keep it around for some reason We could talk again either offline or on this call next week to see why he thinks we need it and whether Everybody agrees or not. Um, but at least it does seem like everybody's going to try to do most of their work in the java sdk Um, I mean and they pause there lance. Does that fairly summarize it? Yeah, I think so, um the The sort of alternative that that I had proposed landed yesterday So, uh, so that's what's happening in the javascript sdk Yeah, I I don't see a reason to keep the typescript thing around but I think it's probably good to talk to Grant about that Yeah, because I don't want to do something that he that you know, I don't want to misinterpret his comments So does anybody on the call think we need to keep the typescript sdk around? Okay, cool. I will reach out to Grant and see where his thinking at is on this. So thank you everybody All right now to the main show. Um, hey right at the top of the hour. Perfect. Okay. Um Trying to figure out the best way to approach this going forward. Um So let's start over here Because I think like you added a comment here Um, I guess what I'd like to do is have you sort of summarize your comment here because this is on your pr And then see what kind of comments that brings up and see where that takes us in terms of a of a discussion. Is that sound fair? Yep Let me know when I'm ready. Yeah, go go ahead. Yeah, okay. So, uh, basically, uh, this pr We have discussed it as a group several weeks ago actually spent about an hour Um, the gist of this pr is to streamline kind of simplify the cloud event interface within Java sdk to make sure that it stays simple concise and represents the Cloud event as defined by the specification and keeps both optional functionality as well as the auxiliary functionality out of it So that's the kind of the the gist of this pr. However, in the process of doing this and There was quite a number of disagreements on Once those auxiliary and optional operations are moved Where are they moved and why here and not there and how and so on and so forth. So um After sort of reviewing all the comments and some of the Thumbs up thumb down and the other kind and responses. It actually appears to us that There's really not a whole lot of disagreements here rather if you kind of Look at them separately and so what I did with this comment is attempted to basically outline The three contentious point There's three contentious points That I believe are part of this pr and basically make a proposal that simply states that okay We're going to cancel this pr and instead we're going to open three different issues And provide three different prs which essentially basically kind of breaks down this problem into three individual problems and by doing so, you know, we'll we'll we'll get to the same sort of result but We'll get there Gradually so the three points of contentions as we believe they are the builder methods that We believe should that should be consolidated and moved into Kind of a version right right now. I moved all the auxiliary functionality into a single generic, you know, catch all utility class with exclusive comment that we can address it later, but You know, I'll be the first one to admit that sometimes later doesn't come and it sits there forever. So Fine, so and as I said in my comment, it appears to be actually one of the sources of agreement that as Mark suggested to have a version builders for builder for version one and go to version two and kind of Consolidate all those methods around there and that Not only follows some of the best some of the typical or expected Java patterns It also provides a consistency of how the cloud events are going to be built Now there is a second point of contention is the encoding operations, which is basically The structure to binary binary to structure the vice versa So again, the suggestion was that I believe we kind of can get all behind Is to create some kind of a encoder utility or encoder like message encoder or cloud event encoder We can argue about the name during the PR discussion, but and this is where the the methods which Do the structural and binary will get moved and last but not least and I believe that's the least contentious point because we kind of agreed agreed on it on the very first call after clements showed how they did it in in C sharp as decay and provided some Justification of or some bro use cases where this would be kind of important Which is basically provide irreverable access to attributes not just access to individual attributes So we're we're definitely have no problem with that So and the the rest of the comment is basically the titles of the three issues that we're proposing and I'll stop here okay Any comments from the group before I add my uneducated comments Okay, so So in my limited understanding of this it seems to me that the third one um May not only be The one where there may be a possible agreement to come to first But it actually may be almost at the heart of the other ones in the sense that I kind of get the sense that if you can resolve three and decide how you're going to access a cloud event and its attributes The shape of the cloud event interface whether it's just one interface whether it extends other interfaces that kind of stuff It seems to me that if you can resolve that The other issues may become less contentious Is that a fair way to summarize it? In all fairness, I don't see the relevance But I mean the attributes is basically it's more of a convenience to give iterable access to attributes The the builders the encoders I mean, maybe I'm missing a point. No, okay, I guess then maybe elaborate a little bit on why I'm saying that um when I when I look at things like the the builders stuff and Obviously correct me if I'm getting any of this wrong because I'm I'm still kind of speed But it seems to me when I look at the two different views of the world When you guys talk about using a builder to do um Some of this stuff I what I'm hearing from from francesco is we may not necessarily need a builder interface or a builder class to do it He he seems to think that we can do it by leveraging the the visitor pattern instead and And when you sort of compare those two views and this is where I get a little fuzzy on whether I'm right or not I almost wonder whether The builder stuff is can be implemented as a layer on top of The visitor pattern or whatever mechanism you use to extract the attributes from A cloud event Right or just set them in a cloud event, right? So I'm wondering whether there's a layered approach here that says If the native way to talk to a cloud event to get its attributes and set it attributes It works for you whether that's direct getters and setters whether it's a visitor pattern Go for it but But let me just finish and then you can correct me where I got wrong Yeah, but then if you want something that's maybe A simpler user experience if you want to put it in those terms That's where the builder comes into play and so I'm kind of wondering whether there's a layered approach here That we could take to solving these problems and let me pause there and see where I got it wrong You didn't get it wrong. It's more like We can impose either mechanics of how to do things so we can say Here's the cloud event Which here's the object or type representing cloud event I can look at the specification. I can look at the type everything aligns one for one It's clear. I can go consult a spec and understand how things are aligned within the code and You can tell me by the way We have this utilities that you can utilize visitor patterns and build this or do that or whatever Or we have a builder or I can do my own builder I mean, I don't have to be forced to Create a cloud event or any kind of object Unless there is a very very specific case for which I can only create it in one way in one way only But we're not even there yet. So not even going to discuss what those cases may be. So So the point is that like I said the gist of this entire pr like like all the contentious issues unfortunately are not even At the core of this pr. It's really at the peripherals. It's like, okay, well Um, are we going to call them builders? Have we call a column visitors? Are we going to call them encoders? Are we going to call them whatever fine? We can have this discussion But the real gist of this pr is to make sure that the cloud event Stays simple stays concise represents the actual cloud event as defined by the specification And operations such as building converting transforming encoding reading writing Are implemented in the appropriate places But those places are not the cloud event Interface itself. Okay. So let's let's let's build on that then because I think that is then focusing on number three And so why don't we why don't we take the next step and dive a little deeper on What we think the cloud event interface should look like and see where we disagree? Is that sound fair? um I it it sounds fair and That yeah, so that's what This pr if you look at the state of the cloud event interface in this pr Then with the with the addition of iterator for attributes Or iterable access to attributes That's pretty much you can click on the actual Sorry, because you look at the diffs if you look at the yeah there and then click on source use source Or if you file. Yeah That should show you what it so in other words the only it what is missing Is that point three which is addition of yet attributes? Like as a collection. Okay. So like similar to similar to get extensions Okay, john your hands up Yeah, so sorry for a semi meta question is Given that we have support for multiple languages. Is there Is there some discussion? Is there some I don't know Maybe consistency or similarity in terms of Across languages, right? Is does that help does it does that help inform some of these? I don't know contentious Discussion points. That's a great point and to answer your question clements View into c sharp representation of cloud event Had a heavy influence Because you are correct at some point of time The whole point of cloud events is not to java to java. It's java to whatever or whatever to java, right? So or whatever to whatever so we need to make sure that Once the cloud event is sent We can at least from the type perspective. That's this my opinion We should at least have some consistency and Without even knowing the language I should be able to look at the cloud event representation in go or in C sharp and say Yeah, I kind of understand looks very similar or looks what it's supposed to look like looks like it's defined Looks the way is defined in the spec. So yes Okay, Scott your hands up I think that that's the whole point of the bindings for the protocols, right? That's that's the interrupt piece Clemens original stk Guidance had had a lot of A lot of Requirements on how implementators should implement and The trouble is it's just not idiomatic for different languages because what's good for java isn't necessarily what's good for c sharp or go or rust Or javascript and people that come to these languages that want to develop in go or raster javascript Need to program idiomatically I can't agree more and what we have right now is well What we have right now it looks more like Another language written in java So we Let's not head down that direction quite yet. Okay, okay Um, so okay, so when I look at this, I thank you Scott for the comment though. Um, so when I look at this My general sense is I think in general people are okay with the idea of well-defined getters Now there may be a question of whether they're Immediately on the cloud event or whether the cloud event interface extends another interface I think that's a A stylistic difference, but let's assume for a minute that One way or another everybody you're going to get well-defined getters on cloud events either directly or indirectly I think everybody's in agreement with that in general, right? Okay, so I think then the question comes around The the mechanism by which people can just uh get the generic attributes thing now Oh, like you said that the What's missing from this is the equivalent of Of a get extensions except to call the get attributes where you're turning out Extensions or extensions just add a similar method for a good. Yeah. Yeah. I'm sorry not replace I meant I meant copy this line and replace extensions with the word attributes now As I understand it There are two Patterns at play here or and therefore two differences of opinion One is what you just described get extension get attributes that returns a map versus a visitor pattern and I think I think we need to talk about those two patterns because again My limited my limited use of java is several years old now, but I believe both are valid patterns in terms of Java java developers may use one or the other. They're both perfectly valid So I'm wondering whether the question then is Do we have to actually choose one or the other or can we actually support both? And then we pause there and you guys can correct me where I got my way wrong Scott is your hand up. Yeah, my hand is up again. Um, yeah, okay, so this The get extensions method because there are so many funky Restrictions on the key for extensions in go we decided that this Path you pass in the key that you would like to get the extensions We also provide this method But having both where there's a key accessor because you want to do things like the user brings you a key that's maybe invalid or camel cased but In the translation to a protocol you're going to flatten all the keys As it gets serialized out and then back in you lose casing so The We found it was important to be able to have the user provide the key to access the map As a convenience because the keys are kind of broken. They're they're lossy So Francesca I'll get to in a second. I'm just want to make sure I understand what Scott was saying So I understand the idea of passing in the key name as a parameter. I get that Um, how do they find out the list of key names if they don't know them in advance? You also offer up like a get key names type of operation Uh, we we provide the a map accessor like this then you can look at the map and look at the keys if you want if you want to iterate Oh, so so okay, so you have you have a get attributes method that returns a map and then you also have a get By name kind of a thing. We have a get extensions like this returns a map with a key value Uh, and we also have a get extension singular That you pass in the key and the the method will fix it for you according to the spec Okay, perfect. Thank you. Okay, uh, francesca your hand was up or did you change your mind? Well, okay, no, I just wanted to say that I agree with having bought The purchase there is no problem in adding bought the purchase and I agree and also agree with what scott said about having get extension and then More than returning a map. Maybe a more idiomatic way java is returning the The key set so get extension late getting the extension names and get extension And and and the same could be applied to get attributes Anybody want to chime in there? I think if I had to do it again in go the we we do have a concept of Being able to iterate over a key set and ask An accessor to to grab both the attributes and the extensions But we have it as two methods and I think if I were to do it again I would make it one method And then have some logic internally to understand What What like if you ask for a data scheme at a certain version that gets remapped to like the correct scheme key For example And so as you iterate over all attributes and extension It makes no difference to the encoders Is that a visitor To me it looks like to me it looks like the uh, what we implemented in viral message I mean for how you're saying that to me it really looks like what we implemented in viral message We'd accept a very message. We have all this Format spec Yeah, I think we just broke it out into two accessors. There's there's like like a There's a difference between attributes and extensions inside of the go lang sdk, which is a direct translation of the v 0.1 spec where the extensions were in a bag And also some of the limitations on how Decoding works and go So Scott I want to make sure I understood what you said it sounds like you're saying if you had to do it over again You would have a Get attributes which returns a map and a get attribute by name kind of a thing No, no, I would actually I would encourage a get method Get by key and the key could be an attribute which is known or an extension which is in this bag Right and the same method would would access from both places and then possibly a Get me all the set keys So that I can go and iterate over them So if you don't have you know Data content type or data schema set it wouldn't return that key for this event Right Okay, so you have you have a I'm gonna try that. It's different. So okay, you have a I'm gonna add I'm gonna be more verbose than I think you said it, but I think it's the same semantics You're gonna have a but get attributes. Sorry one more one more thing Yeah, this is this is more valuable for the encoders and decoders to be able to do this flexibility I think it hurts usability if you don't have the the strongly typed getters like is shown on the screen here Right, I think we all agree. We're gonna have the strongly typed getters. I don't think that's a question I think it's how do you deal with sort of the generic getter kind of thing like this get extension thing Right, and I think what you were saying was if you had to do it over again You would have the equivalent of a Get attributes which returns you a map of everything You'd have a get attribute keys which gets you a list of key names and then you'd have a get attribute by name type of operation But well, I don't know. Okay. We're missing it. Sorry It depends on what what user you're targeting Right, if it's the encoder, it's I have one recommendation if it's for a user in a function I have a different recommendation Well, yeah, but you need to kind of lump them all together when you define the api overall, don't you? No, you don't have to I I actually agree with that point and we have this pattern for them spring as well where we have accessors so in other words The question I think I believe what is being discussed right now is what Should be exposed through the core cloud event interface and then there is additional sort of Column decorators if you wish wish could expose additional accessor methods that would target specific users and and Yeah Am I correct scott? That's that's that's what I'm recommending because Then the user doesn't get bogged down by like these Some crazy whatever the encoders need to be generic Exactly commonly type like pull data out and they can get access to their extensions the The one meta point was that in in go. I haven't I didn't really get it all the way in there yet, but I wanted to be able to register extension like things that are helpers that get Uh built up in in memory so that you can say like give me the foobar extension Set and it would return you several objects back maybe um hydrated from A different type of metadata, right? So at the most basic level meaning on this interface itself here, uh, what would you guys recommend? My my is add one more method that's get extension And pass in a key so that you can plus one You can help get the uh, correct casing of the key I agree with that Vincisco and scott the same for attributes, right? Um No, no, I completely agree with that. I mean, uh get extension that gets a string as a key. Yeah for sure I don't see a harm in exposing the get attributes If you're gonna do that I would I would actually say like get make a method called get with and it passes a key and that key gets translated into either the smart mapping of an attribute or the smart mapping of an extension that guess Is an extension Hmm Not ready to make that decision Right because like from the user's point of view They don't really care that it's an extension or a first class spec component. That's that's just noise that we've made But it'd be kind of cool to be able to say like get Trace or get time and it just kind of works I mean I I wasn't Ready that it's going to go this direction I'm all for it, but I just thought that would be too much of a One way you can achieve that kind of layering is if the if the if the core attributes are defined in an interface and then any of the access any set of extensions can actually extend that Interface so the implementation type extends the core as well and then you get you just add the new getters But from a user's perspective, there's a single type that gives you the composition Am I wrong or is this Is this headed where you guys are going? You guys keep talking about attributes versus extension. I wasn't sure whether you're mixing the two or Or you're trying to is different from the point of view of a function Yeah, remove a lot line six remove line six Why would I remove line six? because we have individual I think to scott's point scott correct me if i'm wrong Either remove line six or remove attribute from line six That's right. I would remove attribute from line six. Okay um Elaborate on why what's the difference? What why does have no word change anything because because it doesn't really matter for the user He wants the user just interested in the key value pairs So user says give me foo and if I discover that foo is an attribute. I'll give him an attribute if I discovered It's an extension. I'll give me oh, okay. I was using the word attribute just mean both in general Okay, now I see why you want to remove the word. Okay. So one one one other recommendation was would we need to not use the the Base java object type here Because the type system is very limited inside of what can be an attribute in an extension You might want to change some base class that says it has some like awareness of what cloud event types I I try to I try to work on that and I try to create a union type but Union type are They don't really they don't work really well with each other. That's what if you pass What if this things just can have a you can we can have a marker interface for that? That's you know, I think Typically, this would just be a parameterized Interface so it would return t on whatever But they're returning the That's how the original interface was and it was super confusing. Yeah, it is no to you in the line six Return return t It could be eventually a problem because maybe the user is expecting a type are This doing a dump on the version that that is not all is not the same as before and It gets cast exception without any reason. Yeah I'm more forgiving an object. So the user knows that it needs to do the check By itself doing an instance of the t will give you An ability if you do know because t can always be you can always Cast it to an object But if you actually do know the type and you're sure about that then let's keep you the casting This is it's more it's more defensive thing towards the user. So the user can't fail can make it work We we are we use we use in order I use the in order project to return things from a generic map like that using get and returning t and Most of the issues people opens are about that So I'm more for keeping object or having just an extension of object So Hopefully I won't completely break everything but let's hold that discussion just for a second Because I want to make sure I get something else right here first. Yeah. Is this right get attributes because I I'm Okay, not being a java guy anymore I'm I'm fascinated that this one is generic It can go over spec to find attributes as well as extensions But then we split them out here and I'm wondering would we not offer up a one that gets everything all at once I think the scott's point is more of a How like if I look at the cloud event and I read the spec and there's a there's a Explicit points about extensions and attributes and I can see them and I can retrieve them as such But then as a convenience for developer You have additional Sort of getters like the one on line six, for example That will allow you to we can java doc will specify that it will actually give you either one, right? So it's more we need to Line five and line three in my opinion corresponds directly to the specification line six is icing on the cake Interesting because to me the spec doesn't make a distinction It has It has it has well defined. It has well defined attributes. I agree with that obviously Um, but for the most part it tries to treat extensions and attributes the same Well, that's part of the problem, right because you don't know the type of an extension Right attributes can are known and they have a specific type extensions can be any type within the limit of the specification and they can be Uh conflicting types for the same key for different vendors Yeah, yeah, not this ground that's what happened when you serialize to jason and you read from the other side If when you serialize to jason you add An extension with the time and on the other side when you read it Uh The deserialization process won't recognize that that's tight. So when you when you read it You maybe you're expecting a time, but in fact you will get a string Okay, so I okay, I'll I'll I'll pull back from actually trying to have an opinion So, okay, you guys are okay with separating extensions from attributes Ignoring this question of type versus t What else is missing here or is anything missing? I'm not going to nothing Uh, this is the subset of the interface, right? But yeah, right I think the thing that's missing and I think the thing that would make slinky happy Putting words in his mouth. Yes, please there are We need to take out just take a pass at making the Interfaces for each persona that we are trying to target and the there's one for the encoders and decoders and there's one for the consumers There's probably one for the producers No objection here. So the producer interface is full of the setter methods which could be implemented by a builder The the accessor methods is what we're we're talking about right here I question if git attributes is useful for an end consumer, but I I don't really have a problem with it It's really useful for an encoder. So the git extensions and git attributes for an encoder is Uh, makes the job very generic. That's nice Uh, okay. Yeah. Um, dug line one. Uh singular not true Thank you Okay Um, uh, slinky you want to chime in? Uh, can can you repeat the question? I'm just wondering. Oh, sorry sky cloud. Yeah The the question so okay. Here's here's this then there's another interface. That's like cloud event Writer or or something and then there's another one that's like cloud event. Oh, okay. Yeah, uh, that's what I made That's what I that's what I made in my proposal. I called it visit or visible, but it's it's really the same right, but uh, Extended you have a cloud event extend from so you basically Yes, that essentially means that all those methods are now part of cloud events Yes, of course, and and there is a specific reason. I don't want to have I don't want that an third party implementer of cloud event Eventually implements wrongly the cloud event interface. For example, not implementing cloud event visible, which is the proposal that I made and in that case The sdk needs to perform some copying needs to perform some expensive operations for writing out the message so What I'm trying to say is that I want to be defensive in that sense and Ask to the to the party implementer to implement the cloud event visit method Of course I I propose of course what I propose in the pr and I think You people are really look at it Is that I I'm giving the fault implementation for this visit process So who he implements the third party implementer for the cloud event Interface done don't need to care at all about that because it's already given to you by But the care of event sdk these implementations the problem with bringing this implementation Whether I want it or not is that sooner or later They bring additional obstruction additional dependencies on the class path and so on and so forth We're all I care about and we already discussed it Sort of many times over that I may just care I may only care about cloud event type for inner process Communication between methods between operations and so on So yes, you can we can have a visitor. We can have many different specializations as Scott sort of points out right now But it's the implementation that should say, okay cloud event implementation Implements cloud event cloud event access or cloud event visitor cloud event this cloud event that that's fine That's perfectly fine. But when the core interface Extends from another interface It's as if the core interface and that other interface are the same thing Emergent to one so in other words, there's really no no reason to break them apart if the core interface extended because every time I deal with cloud event interface. I'm also dealing with that other interface I don't see I don't see the additional dependencies I don't see the additional dependencies the requirement for the implementation to implement the entire buffet of interfaces Versus oh, yes, of course, of course, but that's what I said is that I provide the fault implementation So who implements that doesn't need to care about that because I already implement that That means that it's an abstract base class not an interface Yeah, no, no, it's an interface No, I think it's the fault implementation of methods in a in a Java interface The way I look at this the simplest implementation the simplest use case should be met by the Bottom-most layer and the simplest use case. I think is a function that's receiving a cloud event and Calling getters and nothing else and and so the core interface should only meet that need and then Builders and encoders and any visitor can be layered on top of that for other types of these cases correct Yeah, that's that's how I've traditionally done Java too Right like you you would spend a lot of effort making these cloud event writers and readers and then you make the reader writer encoder builder factory Implement all those interfaces. Yeah, you can compose them together into an implementation So that you still have that convenience for that user So I think you understand this correctly the the sticking point is whether cloud event extends event writer or whether an event writer builds upon cloud event I think what we at least from what I hear from mark and scott is that Implementation any given implementation within SDK outside of SDK Can choose to implement three four five ten twenty different interfaces That's up to the implementation, but the interfaces kind of the marks point Should give me the simplest thing Possible and if I'm only interested in receiving like a function cloud event to cloud event receiving cloud event Acting on it and then returning it or returning him, you know Then I'll just I should be able to only deal with that interface and no additional baggage that it may bring me That's right I have a take it out right like you can make a generator needs cloud events for testing and just implements the reader or whatever I mean testing again, but I don't mean like when we want to get in a direction But yes, it's it's really like for mark for me different other purposes Okay, so Yeah, I I have just question for you. What should the SDK does? What should the SDK do? What should the SDK do when? I need a cloud event reader but Because for example, I need to implement an even format and implement a protocol binding But the cloud event that you provide to me Doesn't implement the cloud event reader It doesn't have to you can have we we're not against readers And what we're saying about cloud event reader and writer interfaces. This is just us debating right now we It's a separate discussion about and we like in a in a in a proposal that Outline in a less comment on the PR We kind of eluded what what it could be because we already have builders we can extend upon that. We already have The concept of encoders we can expand on that. So in other words, there are just like in java We have input readers input writers. There are separate the strategy. There are separate interfaces. There are separate classes out there so And for different Providing you with a different reading and writing strategies for input streams for files for this for that So the same thing here. We don't have to kind of reinvent the wheel So you give me data and now I have a whole toolbox which allows me to Deal with this data either transfer converted from one representation to another Write it to a file send it over socket do all kinds of different things. That's Has nothing to do with the piece of data itself Sorry, but I don't know this is your question. Yeah, your answer. I mean what yeah, I need I need let's say I need to implement An even format, okay I expect by the interface a cloud event reader because I need something that allows me to Access us in a structured manner to the event with less over it possible So I expect expect a reader, okay Uh, if you provide me a cloud event Implementation which doesn't implement cloud event reader. What should the SDK do? It it blows up Yes, it's not that and that and that's exactly my whole point. I don't want to create this behavior I don't want to have this. That's why I'm saying why my opinion cloud event reader should be in the cloud event interface But you why doesn't have to Let's cut them sorry We use these interfaces to separate the concerns inside of the implementation So if if that function is that that's consuming the The cloud event is it's only It's only asking to be a cloud event reader Maybe maybe the problem is that the interface cloud event is is untrue and there's an only an implementation That's called cloud event and it implements reader and writer possibly, right? That function only expects to ever read and it's not going to take the the object that it got and then pass it to the um Some sort of mutating function because it didn't ask to do that But also i'm still struggling to understand I have an object representing a data Reading writing transforming converting is a whole separate concern just like we have In pure java we have a data and we're writing it to a file So i'm going to go and grab an input stream writer or input stream reader and so on and deal with that so Why I don't expect the file to sort of write or read itself Why should I expect? Maybe i'm missing something bigger here, but why cloud event all of a sudden must Have a reader cloud event represents the event and it contains accessors for all the attributes for me to Literally make anything out of it to convert it to transform it into any kind of representational form I can possibly do I think what you are really missing is the bigger picture that we want to create and we want to we want to have dsdk Working pretty well and pretty glued together So we want to make sure that whatever implementation of cloud event works with protocol bindings and with even formats I think so, I mean you're saying implementation of cloud event when you talk about the implementation It can implement more than one whatever whatever implementation because You came here exactly because you wanted to Reimplement the cloud event interface In our package, which is fine. So what I'm what I'm trying to say you is okay That's that's good, but we need to make sure that whatever implementation you create works well with the other parts of dsdk Otherwise, we are creating we are potentially introducing a bad behavior something that can blow up Okay, can I ask a stupid question? You guys were talking about something blowing up and I'm I'm I'm having trouble understanding why something could blow up So I just wouldn't compile right like it is just not That wouldn't happen But I want to make sure I understand it something would blow up because Well, because Scott you mentioned compile time and I think I that's the one that that's jumped out of me first, right If I am writing code that just talks to a cloud event Okay, all I know is the interface or all I see is that interface on line one through nine And I have a a a class file that goes along with that that knows how to process that that structure If I if my code wants to then Do some additional processing on top of that with you guys calling the readers and writers Then first of all, yes, my code needs to Import the proper library right to to have that the new functionality on that new interface defined So that needs to be in my class path right there at cloud time And then at runtime, I need to make sure that I have the right jar file that has that class for that interface defined Do I have that right? Yeah, okay, so so it would only fail either compile time or runtime if I'm missing the jar file That that has cloud event reader or writer defined Fail at runtime if you try to like force the cast from an interface that's a reader into the writer And I don't think you should do that Yes, that's that's what that's where the problem is is that uh, if we don't force the cloud event implementer to have such a reader you are basically blowing up the possibility to use the protocol bindings and even formats for For that interface that's um, well, let me give you a quick example. So first of all You can force user So first of all, it's again, it's a very common pattern to Change representation of one thing to another And if I have a method that takes for example cloud event writer and all I have is the Reference to cloud event itself, which is which may or may not be a writer There are patterns in their utility classes that allows us to actually say listen Let me convert this if necessary or if it's already a cloud event writer Then I'm going to give you exactly what it is. In other words, basically be a little more defensive as you as you use Right. So that's point number one. So in other words just be Yeah, okay, so but just because So that's point number one point number two. He's looking about protocol bindings. Here's another example so while as like for example, we currently have Quite a number of bindings already we had them for number of years for kafka for rabbit personas would Throughout many different things, right? So for example within a particular scope of let's say spring cloud stream I want to write cloud event to kafka I already have bindings. I don't have to write a single line of code for that, right? So for me, it's just a matter of converting it to a proper binding representation So in other words, there's still going to be some custom within framework within application code That will that need to operate on that cloud event and maybe come up with a custom structures and so on and so forth but it's the Core it's this origin of the Representational object, which is at the heart of the entire effort, which is cloud event Which is what we're simply simply saying that should be simple so any of these possible combinations that evolve through typical enterprisey development are Not just possible, but also simple to achieve Just thinking before I go to you because your hands up next just want to make sure is this actually correct Should it say extends cloud event? No, no, no, no, no, it's No cloudy cloud event is not writeable It's cloud event builder that is workable. So It's cloud event. It's cloud event that extends cloud event reader Which I which you might be our I called it visitable, but it's I think that's we ask the point of contention though, right? Yes. That's a huge point of contention. Yes No first point one I would say that that's what you did in your PR and you did it with a huge and pretty bad copy honestly Because that's really where the problem is is that if you don't If the implementation doesn't support cloud event reader, then you need to copy the data somewhere. This is potentially a huge Waste of memory Let's you you want to challenge me? Let's challenge me on actual fact. So Which copy which copy which copy memory we're talking about because I literally copied your methods and put them in I'm talking about extract attributes At least that's the last time that so your PR extract attributes In the cloud event, which what what memory? Okay Okay But uh, I don't want to get into shouting match, but uh, anyway, um Like I'll answer. No, I'm I'm trying to figure out It seems to me that we're back to or we're focused on one bigger question, right? Does Does the cloud event itself extend Something like a reader or a writer or does writer reader and writer extend cloud event don't have that right It's cloud event that should extend cloud event reader. I understand that. I think that's your position Correct me wrong, but I think pivotal you're saying the exact opposite. Correct. Correct. Okay How do we resolve this because it seems like there's a completely opposite but it's also sounds like technically they're both valid, but I but it sounds like there are two very different ways of using java I would I would actually drop the cloud event interface I'll have it just be the reader and the writer And so what make this a class Yeah, but well if you want to have a re writer a readable writeable cloud event object It's it would be a class that implements the reader and the writer So you're so you're saying that cloud event implement sorry that We think about it. So you're saying that cloud event implement Should that cloud event reader which contains the visitor and then it implements cloud event attributes Which contains the gather for the type of attributes and then it contains and then it implements Get extensions. That's that's what you're yeah, that's what you're seeing scott. I well, so my interpretation is that People tend to want to think about cloud event as cloud event writer or reader interface and because of like the common use case is going to be the The function that gets invoked and it wants to get passed down a cloud event Right, so we want to make people feel comfortable about that But what we actually call that thing is cloud event reader because it has all the accessors That could be a So you're seeing Sorry, so you are saying to rename cloud event to cloud event reader Well, well, I'm saying to make it clear for us in this discussion. I think that's what it's called Right the the projection Accessor and Modifier should cloud event accessor. I mean it's just Well, whatever the the unit amount of java term for that that is There's the interface that's full of the getters and there's an interface that's full of the setters Yeah, I mean, I think it's more common that the the core interface is the getters And except in special cases where you're defining an interface for something like a factory, right? That then you may have setters, but typically getters are on the interface and then there's a builder That generates instances that implement that interface and that's where you have right at this Yeah, if and if I were designing this I would probably I would call that cloud events interface here What it is except I would I might cherry pick out the get attributes map and put it in the cloud event builder interface And have that potentially extend the cloud event interface Or something like that Like to trim cloud events down to the the minimum set that we think a function would use To interact with the cloud event in a read-only fashion But I wish that was the only thing we were arguing about because if if get attributes is only typically going to be used by an encoder and not by function That's handling a cloud event and yeah, I think that makes sense Yeah, problem is that I think I mean, it's it's not I think is that more something that we try is that having some using get attributes It could be potentially More costly because you are going you are going to allocate a map on the odd path, which is something we We can easily avoid using the visitor partner. So again What I'm saying is that you should Try to see this interface also for from the perspective of implementing protocol bindings and even formats So Scott, I want to make sure I understand something. Do you I used to just seem to moving line seven and moving it to the cloud event builder interface Or the cloud event read reader interface Interesting Right. So like in my mind the cloud event reader interface. No, that's the builder. Oh, sorry The cloud event reader interfaces is It probably also has the get extensions as the map Maybe a copy of that But I I I agree with this Scott, but it almost also feels like giving the time that we are discussing Something that we could probably agree in the next five minutes without any issues, but the issue that we can't agree on We Yeah, it seems like worth question is is that the word extends right here Or is it up here That's still the basic question, isn't it? Yeah, well, I I don't think I mean in this case the If the reader is for the encoder it doesn't need the direct accessors Right, because we can iterate over everything with these two maps I don't know That's arguable for uh for what regards them And For for for the spec version. Sorry, and It could be useful to access directly to the spec version for what regards implementing the event formats For example, when you when you are implementing the event format for jason, you want to know the spec version because you need But at this point that thing's already parsed I think I think that the heart of this argument is that we need to define the these minimum interfaces Keep all the way down to the very very minimum that it needs to for each persona to use Though then the the implementations can require that whatever object you pass in implements Several of the interfaces that we've defined at the base so that it can do its job And then everything gets type safety and everything compiles and everything's happy and everything interoperates As long as I have to assembly of the interfaces that it requires Correct I I think Can we move forward with that? Francesco Uh, what what I'm really trying to understand till one hour is uh, what is wrong with having a visitor parking here? I mean Because I still didn't receive that clear answer to that I think the the the thing that's wrong with it is that it forces every implementation to also implement the visitor pattern It doesn't again. I if you provided the fault implementation. It doesn't but you You don't get a default implementation with an interface and the yes here is that No, no, no, no, I mean you do But that's you use the default keyword I mean, I should uh, I showed that in my pr that you yeah, you don't need to provide an abstract class You effectively provided an abstract class which is yeah through the default So that's that's one of those things that gets Sort of abused a lot after java 8 introduced it. Well, this is a this is a matter of opinions really No, but Well, wait, wait, wait, so The scott's point is I mean, this is the one that we should concentrate. It's not about what's wrong with the visitor pattern It's really more about much higher point, which is We have personas we have flavors, right? And I only care about cloud event Just the view of it or I or he only cares about how to read or write with cloud event So in other words, this is again a very idiomatic and a very common approach in java to Look at the same thing through a different type of glasses So, uh, it's not a matter of opinion. It's just sort of how things are Done and being done. So why? Do we have to deviate? from something that is so Basic and so fundamental I'm not deviating anywhere. I mean visitor is the most java idiomatic think you can find everywhere That provides the what what's required to make the visitor pattern work But that's that's a separate concern from all the other interfaces that are absolutely Absolutely All right, so like that that lets us get get you what you want and also let any other implementer also implement what they need Exactly, and then it's really a matter of layering right like layers need to be in the right order Yes, this this doesn't preclude a visitor it's just establishing the The layer upon which the visitor sits This is the heart of how dependency injection works because if you want to inject something that implements a certain Interface it really needs to be scoped down to exactly what you want it to do And then many many implementations of that interface can get injected Okay, so I okay We're almost out of time um I'd like to make a recommendation here. I think a lot of good things have been said I think we actually did make some progress some not a whole lot, but some Would people be willing to have another phone call? I know I'm gonna forgive me for to the europe friends um tomorrow if not Monday I know that screws over the us guys, but you're going to screw over the europe guys today We should probably screw over the us guys at some point too um I because I would I would like to keep the conversation going if we can I don't want to sit on this for another week Or try to do it through github issue comments. I don't think that's the great use of time Would people be willing to have another phone call tomorrow? um I personally would have no problem, but um As long as um I mean, we should probably start and you've done pretty amazing job already, but we should probably start setting really strict parameters because um We seem to Agree on like like again the three of us who commented but um you know Francesca keeps insisting on a specific sort of approach and We need to We need to kind of move on. Otherwise, we're going to be Like answering the question what's wrong with visitors pattern where it's not a question of a visitor pattern and there's nothing wrong with it It's really the question of Do we agree that the interfaces should be a diamatic simple and layered as we all seem to be talking About the same thing. So if yes, then it really is not about the visitor pattern or builder pattern or whatever but rather about okay, we have Accessor interface, which is the most the diamatic the most simple and the most Representational of the cloud event as defined by the spec and then we have other The word escapes me but other sort of flavors that are specific to and I'm going to use scouts for personas that And if you cannot produce that particular interface, then that's your problem, right? But it you know Don't bring me any kind of default that might bite me in the long run because that's not because that might bring some other dependency that I may not be interested No, I think I understand. Sorry. Sorry. Sorry that the How the how the default brings in your dependencies in Because default contains code code relies on apis apis Evolve and and with that evolution that could depend to bring a jar that it may conflict with the jar that I have Can ask if you looked at my proposal for complete like Looking at the default that code because the default code doesn't rely at all on any downstream implementation If there relies only on the cloud event, I have looked and all I'm saying again What why are you? Wait, wait, wait, wait, wait, wait, okay Okay, I I'd like I'd like both sides to Have some time to to cool off and think some more about this But I think the problem is is kind of what you what you said there in terms of okay Are we going to have sort of the alert approach or is there going to be a default implementation of Reader for lack of a better phrase I think that's the the root of it. I'd like to continue the discussion tomorrow Are you guys available at the same time tomorrow and noon eastern? I can't What about before that? Does it can't work Scott could could you make money? I know it's a vacation for us, but could you do monday? Well, I was thinking about you know going somewhere, but oh scott come on. This is far more important than having fun It turns out that everything's closed and on fire. So that's fine. Okay So noon monday can people do that? noon eastern monday sorry Same time as the same time is the normal cloud events call. Okay Is that okay? Okay, so let's let's let's reconvene Um, I'm sure there'll be many background discussions going on between now and then but Let's let's reconvene on monday and see if we've made any progress In terms of our thinking Okay All right. Okay. Thank you guys very much Okay, bye everybody. Bye Bye