 And the service catalog group his name is I don't know how you pronounce it, but it's spelled nail And so I think I've got a little nuts there Yep All right three after why don't we go ahead and get started All right community time So for those of you who might be knowing the call which may just be one person This is a time for people who don't normally join the call to bring up topics They would like for the community to discuss that they're not on the agenda. So do we have any topics for discussion? All right, none moving forward then No update in SDK. In fact, there was no meeting today Demo work so we're making some good progress there I think I was worried to look at the very bottom of the proposal doc for our demo scenario Hold on a sec. Let me see if I can get down to the bottom real quick Okay, that's Okay, it's taken me too long to load but down the bottom there's some sample message flows and Jude, maybe you can paste a link into Into the chat here, but Jude put together a Swim lane kind of flow as well down here at the bottom that you'll see is I'm sorry, so go ahead Jude. Yeah, let me just find that I'll put the link in there. Yeah Basically what we have here is that basically the sample message flows for One complete walkthrough of the demo of somebody ordering coffee Then the supplier running out or the retailer running out getting more supplies the truck handling and all that kind of stuff so This should be getting awfully close to People being able to coat up some stuff Hold on a minute. Let me copy the link here just so you guys can see what this one looks like to All right, so here you can see it We're not going to go through it here, but the point here is that if you guys are interested in participating in the demo Join make sure you join the The demo slack channel if you don't in it already ping me And I'll all right you because it's a private channel, but this stock should give you most everything you need in combination with the with the swim lanes We will have a phone call. I apologize for the late notice right after this one To do some last some more discussions about it But otherwise, we do have phone calls every Monday at 1 p.m. Eastern as well to go through it But we do have the infrastructure up and running. I personally have written a Simple function that handles all the various roles and everything does sort of seem to work for the most part But we need more people in there to make sure that that works for in general for everybody So but as I said bear makes no good progress there So if you guys want to participate from a company perspective, please join the sooner you get in there The easier will be for you because this is this scenario is actually a bit more complicated than previous scenarios that we've done So you want to make sure that you have time to get all your code working, right? If you want your company logo to appear as part of the demo right Any questions or comments from either the other Doug or Scott or Jude or anybody else for the demo team Not yet, but you can save them for the post the squad. Yeah. Yep All right. Okay, moving forward then Kube kind of you nothing really much has changed there as far as I know. I don't think anybody's really done anything with the charts I think Scott for was the date you've noticed it was like what may sit this like the official date for when it's supposed to be do but Don't pay attention to those or something like that The the only date that people need to pay attention to if you're supposed to be presenting Is we did agree that by the end of this month meaning the end of April we would have a rough draft available for this working group to review so You know who you are Start working on those rough drafts in those slide decks that we put out there for people to work on We do have a phone call after this one at 1 o'clock So it's gonna be a combo demo call versus kubecon planning call Because for better or worse, it is kind of the same people but there were a couple questions there I have for you guys. So if you can make it to the call right after this one, please do try to join Because I do have some things to discuss there But are there any questions from the broader community about what's going on there? All right Lastly relative to conferences As I mentioned before we do have a 35 minute cloud event session and a 35 minute serverless working session. They were both approved We're looking for speakers. I Will be there so I could technically handle both but I would really appreciate it someone else was gonna be there To participate in the fun I Know I suspect Kathy might be there But I don't know anybody else. So if you're planning going to kubecon China or you want an excuse to go We are looking for speakers here. No more than two per session. So up to three more additional speakers Would be nice or is the option available to us Okay, so it's just ping me offline if you want to speak about that one or speak at that conference Still haven't done my presentation yet for this there's nothing for you guys to review there I Believe the next TOC calls. I think maybe next week. We're going to discuss what independent users means So we're still waiting on that reason on that decision All right, let's jump into PR's unless there's any topics people want to bring up before we get into PR's All right moving forward then Do-do-do All right, so came around this gentleman's name Mike came Mike winters made some changes to the serverless white paper that we produced So while this isn't a cloud events topic it is part of our service working group stuff and Basically, I think that's it. Yeah, he just made these set of changes here This is just a slight wording change. This is the bulk of it down here So I'll give you guys a chance to read this over I think we had two people review it so far and they were okay with it But I wanted to give it the group of broader the broader group of chance to look it over So I'll give you guys a sec to read that All right Any questions or comments on that it seemed pretty safe to me Nothing. All right any objection then to merge in this PR into our white paper No objection, but there is a comment in chat that it seems like a plug Yeah, I that did kind of pop out unfortunately. Well for better or worse We do actually plug other things as well. So I mean for example right up here. We talked about AWS step functions So that's not like this is brand new If people feel strongly about it we can go back to the author and ask him to remove it We just made may appear a little bit inconsistent to be honest But that's what you guys want I'm okay with pushing back on it Well, I my question was actually whether there were other examples of the same thing rather than saying oh, we shouldn't do it It was you know, is this a a unique pattern or you know You know an example of something that is pretty commonly done I believe we do have other examples in here like like the did mention the step function thing I know there are other spots in here. We do Workflow tool with the documenting what decisions were made You know it it's not clear from the text here whether This proof of concept is the first thing or merely, you know, and one example of many I'm sorry, Evan. I miss understood. Okay. It's okay That's why I decided to speak up. Yeah, no, that's good. Thank you I'm not married enough with the space to know the answer that when anybody have an answer for Evan Okay, not hearing any my point of view on this is if there are others and people want to mention them I think it's fair to to call them out. Yeah, it seems harmless to me I just I was curious whether you know a example for a particular consultant Consultancy as a proof of concept was You know If that was enough or if we wanted more references. Yeah, I think I'm fine with naming it as is Yeah, I think we had more. I don't think anybody would check to adding them, but Not hearing anybody speak up We are where we are Okay, any other questions or comments? All right any objection then to approving this one. All right. Cool. Thank you guys Whoops, I can't type. All right Klaus, would you like to talk to your PR here? Yes, so background is that I'm thinking about this Pierre I was supposed to provide for quite a while ready about immutability of event context and I felt it was difficult to speak about this without a few new terms or terms we were already using actually But they are not defined yet. So like producer consumer and intermediary I think is important also for that and So I just tried and came up with something I felt was reasonable, but I'm Happy to get any any feedback and and I don't know if people agree to how I see for example the difference between producer and source That might be one of the things people would discuss about Yeah, so that's the the background Okay Just one things and this doesn't fit on my screen. There's one more edit down here, which changes producer Think or change to producer and consumer down here on this one line. Yeah, so producer for me is always something Let's say active so Basically a piece of code a process container whatever that is actually putting the creating the event in memory and then sending it While the source is something more logical Logical construct That in this abstract way is then the source of the event I mean we have those examples like a GitHub repository or Whatever we have is typical sample sources, okay Any questions or comments for class? Now, I don't know how many people have the chance to actually look at this yet But you feel like this is kind of an important one if we do move forward with it I mean it seems reasonable to me, but I don't want people to rush this decision because this could impact other PR this class studies We're gonna another one that follows on to this Do people want more time to review these or do they feel like what you've seen on this call sufficient to approve it? Or to vote either way I should say Question regarding the description of source I find it slightly contradictory that it talks about source as the logical system or service But then says if a source is not aware of cloud events a producer creates the cloud event. I think If a producer is a specific instance processor device and source is the logical system the source is basically never aware of cloud events because it's a logical system and that That's something actually creating the implementation details. Oh, I Mean, I think we're tempted to distinguish here between for example GitHub Which doesn't produce cloud events, but you might bridge them into cloud events And I think some of the Microsoft's implementations are actually producing Cloud events and so you would think of the Microsoft Service systems as being a source, but you would need some external producer in addition to GitHub to generate an event a cloud event from GitHub. Oh indeed, but Maybe it should say if a source is not aware of cloud events a middleware producer or an external producer creates the cloud event because If the source is not aware of cloud events the source is producer will not create it and that's how it feeds to me at the moment Maybe that's just me Can you say that last part again one more time? I think you lost me a little if it said if it said if the source is not aware of cloud events an external producer or a middleware producer Creates the cloud event. That's just Now it reads to me as if Producers within the source would create the cloud event even though the source is not aware of cloud events I Would be careful of using middleware because I think middleware may mean something else specific that External would be fine. I think yeah, yeah external or separate or something to make it clear that it's not Yeah, that's a good idea. Yeah, okay That's a good suggestion. Thank you Any other comments on this? Okay, I know we had one potential we had an edit here, which is adding a Small little word in there somewhere Any others just edits otherwise? I'd kind of like to say if no one has any complaints or wants more time to review it Maybe we could prove it with that one agreed to change But I don't want people to feel rushed either so don't hesitate to say you need more time if you want it Okay, so class it sounds like you're okay with making that one minor change So if you can make that change and then we'll ask for, you know, one or two LGTMS after that offline It sounds like people are okay with approving this is that okay, is that fair with everybody? Okay, not hearing any objection proved with See this is really bad. You guys get to see all my wonderful Spilling mistakes. Okay. Here we go. All right. Thank you guys All right now I don't believe Alan is on the call and This one was opened up a little too soon for us to take a formal vote on but I did want to bring it up Because it is kind of an important discussion. I wanted to get a sense from the group So Alan is basically proposing that the ID itself Be made optional He doesn't see it being necessary in all use cases therefore it should not be required for producers to include it Fortunately he made a whole lot of other changes, so let's let's focus down on here But basically what I want to do is like I said find out from you guys is how you felt about this in general We can then worry about whether the exact wording changes are okay or not But what do people think about the idea in general of making ID optional Go ahead Jim So don't we have a problem then with Uniqueness, you know the other stuff we've been writing. That's all that included then ID in the sort of uniqueness Yep, it would definitely impact that yes Does he have a specific use case he's talking about here where he thinks the idea is irrelevant. It seemed a bit unusual to me So he does I need to pull back the issue discussion here one sec It looks like some of the examples now this is using source and not subject but Yes, some examples of sources which use a UUID to represent the object and if it was for example object create with a UUID It would be Unusual to get a second create with the same UUID Wait Evan I'm the last man that what's the problem with that? I mean events should be immutable anyway Well, it's not clear that you need an ID for that create event Because you already in the source or subject have a UUID Which is unique and so adding an ID to it doesn't seem like it is necessary Are you saying if a source emits multiple events? if you If the source well if the source string is unique already Do you need an ID as well? Well, the source the source is one entity the events that it emit Should also have ideas I would have thought so you can distinguish between them you don't want a case of Something going wrong somewhere within the one of the transports and receiving the same event multiple times Even for that purpose if you look at the examples that are added in this PR. There are Sources with a universally unique urn using a UUID and Yeah, and files changed. Yeah, but isn't Sorry, I'm a bit. I think I think this is a strange use case scroll back up to 10 If you have a create for example with a source like that There should never be another create with a source like that If it's if that's actually specifying the object that got created So but doesn't that I apologize Jim is your hand still up? No, sorry. Okay, but so Evan I'm a little confused though. I agree with you that if there's a particular event that's flowing around where the source happens to be unique That technically someone could use that same source as some sort of unique identifier but You can't guarantee that at all because the purpose of those two properties are really very different There's different semantics and different purposes in life But that doesn't mean that they couldn't for example take that UUID from the source and use that in the ID field itself Because they know it happens to be unique so it serves the purpose. Well, I'm not I'm not attempting to suggest that this is a good Thing that we should include but I think the thinking is if that source is already unique guaranteed unique using something like a UUID Maybe you don't need ID as well I'm not worried about the extra bytes Can I just add a comment here? I mean it seems on first glance it seems counter-intuitive to have an event without an ID and my second comment would be What why don't we just do the the obvious thing here first for the common use cases and if we hit edge cases then We can push that back to whoever generates the event to provide a blank ID or something like that Or or a essential value or something But it does feel counter-intuitive So if I remember correctly, I think also one of his concerns was Not only that he may be asked to produce a field that is not necessary for his particular use case But also that creating unique ID could be very expensive sometimes depending on the environment I think that was another one of his concerns Just trying to channel him since he's not on the call. Oh Christoff your hands up Yeah, there is in the PR it the first line In the optional part Sorry scroll back down It says like a producer may omit ID if the duplication is not required But I think our goal of cloud events is to say that I write a producer and then later on at consumers So I get applications that I don't even know that will exist when I write my producer So therefore I cannot know if the duplication is not required in my opinion. So basically that That case doesn't exist Okay So I'm not necessarily hearing a lot of support for this direction, but let me be very explicit about that Is there anybody in the call who does think that ID should be optional? Okay? I've heard no Topini Well, I want to go after that. I'm not so concerned about the changes to ID I don't I mean if someone has a closed system whether that they don't need the duplication I don't really care if they use ID because it's a closed system But I'm more concerned with the changes to source. It adds additional constraints That this is not only a change to have an ID, but a big change to how source works Yeah, I wasn't gonna get to that yet because if we if we didn't like the idea of ID Then I didn't I wasn't gonna worry about the changes to source. Okay Right So let me ask this there are several people on the call who spoke up who seem to have some concerns with this and like I said Because it's so new we can't technically vote on it either way anyway, but can you guys add comments to the PR itself expressing your concerns? Just to get the conversation going within the with the pit within the PR itself because I don't believe Alan is gonna be able to make these calls in general since he didn't make it today By the way, he can you guys can have a discussion within the PR. Can you guys do that? So I'm trying to remember who spoke up I think Evan you might have spoken up and then Neil you Okay, cool. Thank you very much Okay, in that case, we don't need to dwell on that Since we need him to make the case for it And obviously go back and look at the issue that I pointed to because he did make some arguments in there Which you may or may not find compelling, but I think it'd be worse for you guys to are useful for you guys to read that Alright So okay, so this one we can't talk about because we're still waiting for James to get back to me on that one Yeah, I was going to come up and remind me of that. Okay, so Let's talk about uniqueness. Well, hmm So Scott, let me pick on you for a sec since you're very heavily involved both these issues of the uniqueness stuff and the quoting for a should be headers Which one would you like to discuss first? that He may having zoom issues. I see you bouncing up and down there Scott Yeah, okay Okay, let's take him in order then unless skype when he finally gets off his zoom issues Well, unfortunately if he can't kind of zoom he's probably the one the biggest advocates for changing the scope So we need you Scott. I may be able to speak to some of them too. Okay. Well Okay, so let's talk about the scope of uniqueness So as of today Okay, so first of all this PR is basically advocating I don't think a semantic change rather a clarification because the spec in my opinion in a way strongly pushes towards the idea of Ideas unique from each producer so that if you can then combine ID plus source That's going to give you some unique to pull that you can then Say, okay, if I see this couple again someplace else I can dedupe it if I wanted to answer this PR I think just tries to clarify that I don't think it actually tries to change any semantics I could be wrong, but I don't think so However, as part of reviewing this some people in particular Scott raised a concern He said well, if we're going to go for some sort of Ddupe logic or uniqueness, you know, it's a more unique the statement than there He believed we should add some other properties to there. So for example, I think he at least wanted type And he may have actually also wanted subject to be pulled in as well I think it's both subject and type. Okay. There you go. Thank you. And so the discussion here for the group is Do we want to do that No, we did just for more history We did briefly discuss this on a phone call two or three weeks ago camera win Unfortunately, Scott was not on the call then to advocate for it But there wasn't a whole lot of people speaking up saying we were they want to change things That's why we didn't do anything formal because Scott was on the call So either Scott if you can talk to it or Evan if you could talk to it Can you explain possibly why ID isn't sufficient from a particular producer? I Think I think instead this is more to assist producers so that they Don't end up needing there may be a natural unique thing. That's an ID But you may end up wanting to publish two different events for that same natural ID Because the requirement is that IDs are unique if you already have some system like a database that is giving you unique IDs It might be natural to use that however, yes, I Think fire. I think the firestore documentation is what I've been quoting You might publish both a object created and a object updated It would be nice if you could use the same ID for both of for both of those Because you already have a natural database ID Similarly including subject if your natural ID was something like a Generation number that counts up it might be unique on that particular at CD key, but might not be unique globally, so if you said that that for coordinate of type and Type source subject and ID is unique then That basically aligns with your schema in the database and you can Ensure uniqueness using database properties rather than needing to make up a number Okay, anybody have any questions or comments on what Evan said? Oh, come on You guys can't be quiet. So a another specific example is publishing Kubernetes events which have a generation holds from at CD if If we believe that the source and subject split is useful The source might be your Kubernetes cluster, but then the subject would be the particular object that was updated Okay, I don't think I'm gonna raise my hand so I'll raise my hand because I have some things on this one It seems to me though that there's a little bit of either confusion or potential confusion with sort of the path that you're headed here because While I agree that the entity that is producing the cloud event itself may look at some incoming field and say oh, okay I can use that field for the ID It's still the the cloud event producer's responsibility to make sure that ID is actually unique Because the minute you start making assumptions that it actually has some other semantic meaning like for example I think in your example you had the same ID being used for the create and an update the minute you allow those to be Shared across events You almost get into the situation where you almost have to define the semantic meaning of what it means for that same value to appear in both events and We don't really need to get it hasn't been our position to get into explaining what a lot of these extra fields mean Especially from an application level perspective So I can trivially make them you make those two unique by putting a abbreviation based on the type in front of that database thing Right, and then I can make the IDs unique But that seems like I'm adding extra work to the producer for the purposes of adding extra work to the producer And it doesn't really seem like Saying hey if you want to publish these two events You need to put some uniqueifying thing in front Adds a lot of value to the downstream consumers who could still just take off that prefix and try to match things together We're not saying that they would have to be unique. We're just saying They're allowed to be the same if they're different types of events Yeah, but I think what you said there's kind of interesting you wanted a consumer to be able to let's say We did munch type in an ID into one field like you're suggesting You said a consumer there would could split of them apart and and look at the ID part and do some reasoning about that But I would actually I'm actually saying you could compose ID With some prefix that's related to the type and that unique database Sequencer that you've already got right right. No, I get that but then you said the consumer could then Split off, you know, take off that prefix and be left with the database ID and then do some some logic based on that And I would actually argue that that would be misusing our spec to do so because We don't define Well, I was right. We don't define the semantics of this ID to mean anything other than it's just unique right some advocate if you want a field in there that represents some application level semantics so that people can Correlate events in some way I would suggest that there's some other field that you guys should use to do that or and create a new field But this field is not meant to be used for that kind of correlation and and try not to use it for that would be I'm not suggesting using it for that correlation I'm suggesting if you want it to be unique if you have a database that produces unique identifiers That's a good way to make sure it's unique Yeah, and I kind of that's the way I kind of view it which is the it's the producer's job to make sure it's unique and if for whatever reason this producer Doesn't have unique IDs on its own but between type and source to become unique then do exactly what you said You know string cat all of them together stick that an ID then we should probably just document that Yeah, I would I would much prefer that type of solution and with the recommendation like that simply because when you get into this notion of Different, you know like four different fields to combine make something unique. You then have to explain. What does it mean when only three unique? They're different. I mean, they're completely unrelated Well, but then but what but the but then what's the point of allowing it? I'm not gonna freeze right where it's something to stop there. It just seems awfully weird. So Okay, I spoke too much. No, that's okay. No anybody else wanted chime in here At the risk of Google are you with Google? Go for it. I Like my conception is if you are emitting an event you are a source And I don't like and it sounds like that is not your understanding By the definition of the PR that we've reviewed half an hour ago. It's there's there's two bodies there there's the source where the event came from and then there's the The adapter that's actually making the event into a cloud event. That's what we're talking about But from the turn like in terms of the cloud event isn't like isn't it a source for the cloud events? Is that wrong? I've always interpreted as the Okay, that's all Scott gets back Rachel. Do you want to keep going? Do you want to wait for Scott to get back or Should I move on to the peony? No, I don't I don't want to No, I think I think we have different ideas and I want to let him represent itself. Yeah, okay We'll come back to Scott in a sec. Oh go ahead Scott the The source of the event is you know, like let's say GitHub the adapter is the thing that's Actually converting it into a cloud event. I think there are two different roles But the source if you want to go look up The original like where this event came from and you're assuming that the Adapter is going to modify this source. I think that's a different kind of line to the consumer of it and it becomes very Very difficult to understand how to go and fetch the content The actual PR content, right That's okay Can you elaborate a positive jump here, but just for clarification you said the adapter would modify the source Why would it modify the source? No, I don't I don't think it should it should it should say I this event came from github The type so I guess we need some guidance Knative chose to use type to encode the entity that has converted that into a cloud event and And thus it has a different schema than the original source emitted because now it's a cloud event That schema might be different if there are two opinions on how those events get converted into cloud events Is this I'm just wondering are we verging into the mutable or immutable cloud events space as well here? like does middleware need to change something to Make that coordinate none, you know different if it goes and adds a contacts attribute It's but it's not middleware it's well, no, I'm wondering are we Verging into that discussion We could be it kind of is middleware So I feel like we may be verging to it, but I'm not sure we should So let me go to the queue since some people are waiting to be your next Yeah, sorry to bring this magic issues again, but according to the PR that we just reviewed That added the definitions for producer and source this PR clashes with that because it says Each distinct producer must have Unique source and that's In here, we say a specific instance processor device would be a producer source would be the logical system, so I would I would think that the new PR would say that each source must have a different source Which is kind of weird to say but the field each logical system that is source as defined in this PR We accepted must have a unique source it's simply a Terminology problem with the new PR So I apologize I got lost in that are you saying you could modify the text here No, no, no, no in the other PR if you look at this an application must assign a distinct source To each distinct producer instead it's according to that other PR It should say an application must assign a distinct source to each distinct source Okay, that's exactly what I'm talking about So there could be more than one producer producing for a distinct source in that case like how do you understand? the resulting cloud events that come from those two producers I Guess I don't see the problem Well, the problem is that they have different schemas because they made different choices The producers are making choices for that source because they don't produce cloud events Right, but they they could still have Same producer can produce two different events with two different sources or the same source doesn't matter But the producer is just responsible over making sure that whatever ID it chooses there is unique, right? Is Single producer like a unique ID, right in there are two producers and there is one source That seems to contradict the sentence that will balance is just by So it says an application must assign a distinct source to each distinct producer so how could there be one source and Distinct to distinct producers easily. Let's say you have a distributed system that has a user service He has two instances of a user service Those both are distinct producers But they would create events with the exact same source because they are part of the same logical system That's but I so I combined that scenario, but I still confused as to why that's an issue Why isn't it just those producers each those producers must make sure that the IDs they produce are unique Yeah, have a UID. That's what UIDs are for Yeah, I guess I still don't see the problem I mean my problem is just with the wording of this PR. It says each distinct producer must have a distinct source Which I think is simply false or wrong according to the terminology we just accepted I don't really know about the ID stuff. I think we should have a unique ID, but This conversation is beyond me Okay, so so to be in doing favor make a comment on this line because I do think that's a good that's a valid change That we need to make it irrespective assuming we Don't completely ignore the entire PR but I I'm not actually talking about necessarily approving or disproving or rejecting this PR itself um I'm more talking about the concept of whether ID is sufficient for uniqueness or whether we need to pull in other attributes I think it's I'm sorry say it can reach out I think source and ID are unique and can be used to do and like I just don't understand the like if you have If you have something that's creating a separate scheme as in why can't they just each create a unique ID? Like if they all have unique IDs, then it's okay Yeah, because the ID comes from the source comes from the original event But that's the producer's choice and I think I'm not sure you heard evan's comment earlier about how Technically the producer could choose to take the subject the type and the ID from the source and concatenate them all together And that creates a unique ID If that's if that's what this particular producer needed to do in order to make sure that everything was unique So we go our statement of guidance more than a spec change So my idea is not needed. We can delete ID and just use Type source and subject. No, you still know we still need you still need But why it's it's in the subject No ID provides you a unique value It may be if you have something in your database that's only unique by subject Then maybe you mix the subject in with that database sequence number You can do it by concatenation. You could do it by something like You know using a hash if you really want to make sure that people don't do the Oh, look, I can split this string apart thing that Doug's worried about So internally at google we have several systems that are based on spanner That pass their clients opaque tokens To allow consistent reads And in many cases that opaque token is actually just a spanner sequencer But they tell you hey, it's a set of bytes. You can't figure out what it means. Just send it back to me And I'm imagining that ID could be treated that way, you know, it's a set of bytes. We guarantee it's unique And maybe it has some meaning, but you don't get to care And to be honest, that's the way I was interpreted ID, which is why I get very nervous when I hear about people using it for some other purpose Oh, I'm I'm more worried about how does a producer actually ensure that it's unique I'm not I'm not recommending that downstream systems try to Use that property for anything other than uniqueness I'm just trying to make it easier for producers to produce Guaranteed unique values Yeah, I understand I so I think at one point when scott said let's just remove id I heard rachel jump in and say no But I could have sworn I heard another female voice back there saying no as well Was there someone else who wanted to join in? No, I there are people around my desk. Oh, okay And I was like great. We can have another participant in this Okay, maybe not okay, um Anybody else have any View on this So just a question really uh, this is not it They even assume that they somehow They have been able to unique identify the The source and produce or things like that, but it goes to the adopter, right? That's what you said Now those fields are going to be carried out through the adopter or adopter does something else So you lose those identities Who is that question for scott I guess I'm I'm asking genetically here because my understanding is you said This is going to go to an adopter to become a cloud event And in that adaptation Do you lose this information? Do you lose this uh unique identification in the in the adaptation later? If I understand your question, I think that's up to the adapter to decide how it wants to get its job done It's only required because that's its output produce a unique identifier Where it came from is completely up to it Right, but so are we putting as a requirement what the adopter should do here or are we going to leave it alone or what? As of right now that is not something that we get into the spec just defines what goes on the wire It does not get into how somebody produces the information that goes on the water. At least I don't think it does Well, okay. I mean the information on the wire. So if it does not be modified, then no problem Uh, but if it gets modified Then do you lose this unique identification or not? We keep trying very hard to create a unique identification here I think in this case the adapter that scott's talking about is not an adapter from one cloud event to another It's just some random bytes from from some random event And turning it into a cloud event And so in this bigger case, it's not like there's some cloud event ID that's getting lost or changed in the process It's it's actually creating a new one from scratch. I believe Oh, okay Anybody else want to chime in here? Okay, so so scott. I wanted to get your take on this given everything that's happened here Oh What would be what would be your reaction to Taking the taking the path that I think evan was possibly suggesting which is Add some guidance someplace around The about how to create uniqueness Right, that seems intriguing. Let me go back and give it a try. Okay Okay, okay in that case um Any other any other discussion points around just the uniqueness aspect of id You want to bring it up? Okay So let's scott Okay, you'll go off and talk or investigate that side of things I think given that this this pr has had so many discussions back and forth I don't think we can review this one yet because we need to wait for that conversation to finish So i'm not even going to push for any kind of vote on that one um We have 10 minutes Scott is there anything within say five minutes that we can talk about relative to the Http header issue, or do you think that's too big to even start a discussion? Oh, does anyone care? I guess you could start there You want to remind everybody in like 30 seconds what this issue is about? We don't like the quote in a string. We don't think that Http binary headers should be the json bytes that got decoded So basically what the current spec says is decode the message as a json But bag of bytes take the key that would be the value for the json key and stick it in the cloud event as a header value And so the string gets bytes and then that string gets closed Uh-oh, do we just cut? Man, it's so weird. Okay. So just to finish it out. Look at this example right here. This is what the spec Oh, you're back. Anyway, go ahead So yeah, so the spec says, uh, the string has double quotes in it And the way you interpret that is you json decode that as raw bytes But it's a string for real because it's a http header and they don't send bytes over http headers So we're saying don't do that Just let's see it as a string and if you you understand the strong type then Understand the strong type of parsing like that. Yeah, I think the problem that comes across. Oh, sorry. Go ahead, Jim Yeah, I um I think I'm going to channel my inner Clemens I I understand. Yeah, it grates on me slightly as well But I don't understand how you could do backwards and forwards Translations between structured and unstructured for instance and end up with the same json representation You might be able to do it for our defined context headers, but as soon as you end up carrying Extensions around I'm not sure how you could reliably go back and forth between the two Encoding schemes I don't see any of those. I don't think it's the hand ups. I'll jump in here too. I I think the other problem is Between extensions and non extensions, right if you have an extension today and it's say an integer How do you know when it comes across the wire whether it's integer versus a string and then when you promote it for real If it if we don't know the type it's going to make it a lot harder for people Um, I one of the ideas is a problem with an extension. I don't know versus an extension. I do suddenly know about yes But I think I think what's interesting is and sky and I I don't know whether he's serious or not but I I've been half serious half joking about The possibility of the spec not dealing with types at all And everything when it goes on the wire is a string from a spec perspective If something on the other side understands a property and it knows that it's really an int It's free to convert it when it passes on to its application or to its user But from a spec perspective everything is a string And I think that avoids a lot of these problems, but I don't know what people's reaction would have to be I think that's the only realistic way around this Is to move to a completely string based type system or yeah single type system Yeah, and as of right now, I think we only have one type. That's not a string That and it's an integer I came or which which field it is but one of them I believe is an integer And of course we also have maps that get converted into jason structures or some like their strings or something like that So so the alternative to the make everything a string is make everything a string at the top level and don't flatten maps And then you you preserve typeness How would a map look would a map look like curly brace jason It would look like line 279 29. Okay curly brace jason. Okay So that value could be a number and it would it would still parse on the other side as a number But the trouble is if you try to promote a number into the the the flattened Contexts it becomes an issue In this bigger case if this was a custom attribute Um the user doesn't know whether it's a string that just happens to start with a curly brace versus the sexual jason, right? I assume Somebody would have to know the data type it's on the receiving end, right? But what's the difference? Well, it's not I just want to make sure that technically it's still just a string It just happens to look like jason That's right. And and because it looks like a jason object the other side can optimistically flatten it out and give it to you as a uh actual map Not just a string No, I think it should actually be a map if I understand you correctly So in in terms of the cloud events type system, this is a map not a string Maybe we make a mistake there Yeah, so I I thought the suggestion was to Just move to primitive types of string, but still allow maps You would have to yeah, obviously we need to think more about the map case But we're living a little long time But I did want to just bring this subject up for people to start thinking about it And please comment in this I guess it's yeah comment in this pr because this is this is kind of an important thing to get resolved um This this dramatically changes this The serialization rules that we have going forward and we definitely need to get this one fixed So with that Before I go back and do the attendance for the last time. Is there any other topics people like to bring up? I have a short one. Yes, please Yeah, so i'm just looking at the hdp transport binding for c e and uh The content type continues to be application json karset utf Uh, do we want to add the uh the content type extensions such as application json plus? um cloud events version 3 So that somebody knows so that the receiver knows what kind of uh payload this is Now you're talking about the they talk about our property or i'm sorry the hdp spec. Sorry i'm on the wrong expect the hdp. Yeah, uh, 3.1.4 I'm under that hdp transport binding 3.1.4 Yeah, so look at the content type there i'm promoting to add application stroke json. Sorry application stroke plus cloud events plus json That's only for structured data. Yeah, this is this is binary because notice you have the c Attributes, but isn't this structured as well? No, let's see if we can find an example structure. Here's the structured one down here So here we do that because the content in the bottom is a is a c Oh, okay. That's the difference. Okay, got it. Oh, okay. Thanks. Mm-hmm. Good question though All right, any other topics All right. No, I think I either heard or saw dug in the chat of Hobby or victor are you there victor? Yep, okay, I hear you. How do you What about Erica? Are you there? Yeah, I'm here. Okay. Excellent. Uh, we're about Richard Hello, did I miss anybody besides uh, how do you Uh, Eric Erickson's here Okay, Eric. Whoops anybody else All right, cool. All right. Thank you guys very much. We'll talk again next weekend for those of you who are going to the Kukani you are involved in the demo stuff Please hang on the call so we can continue those discussions in the next hour Otherwise everybody else is free to leave. Thank you guys Thank you. Bye. Bye Thanks Unfortunately I'm gonna leave a comment on the 42pr It's getting kind of confusing now that we have a terminology for a source which does not equal the contents of the field source So we I think we said do you want to leave a comment you met on classes pier No, no on the Well, I guess both I should but I don't really know the definitions for the Source in that new terminology versus the field source Results are very confusing text now that I'm writing it out Well, the different. Yeah, the field source says it's identifying the producer and that's then not appropriate anymore Yeah, we're probably gonna have to rethink that I still have a feeling that the concept of sources Well kind of under defined So far we were just using another undefined term to explain it, but Yeah, yeah, it's very nice to have that terminology, but they do conflict now Anyway, let's we probably talk about the next week or something. I'm leaving some comments Yeah, please. Is there any reason to think that we should not merge classes pr? Because I don't want to I don't want to rush it Yeah, I do think so because this is really confusing now that I'm writing it out Yeah, it's it's good. I know I would prefer more discussion. So, okay. Yeah, I don't want I definitely don't want to rush it Okay, let I'll hold off on that but um class. Maybe you can make that one change that someone suggested at least being at that behind us, but then Topini can make his comments on top of that Just a concrete example if I have a source according to the new terminology being to you two instances of a user service As I said, uh, they can still have multiple sources inside them making multiple Is this sort of field source or different contents? That's quite confusing Yeah Okay, um Okay, it's after one o'clock my time so we can get started. Oh, actually hold on a second. Let's see one thing here Oh crap. Okay. Sorry. I had to do my schedule. All right. Where are we? Um, okay, so uh relative to the kukani use stuff itself, um Klaus volunteered offline to speak with scott at the intro for cloud events session Um, so no real question there. Um, just letting everybody know i'm assuming scott's okay with that I already talked to him. Oh, perfect. Okay. Yep. I didn't think it'd be an issue Um, let's see. Vlad and clements still doing the deep dive that hasn't changed okay, so For the intro on the serverless one, I know scott volunteered to do sort of a quick intro there Um, I was going to volunteer to basically be sort of the moderator just for the birds of a feather type session If if you assuming you guys are okay with that The but the real reason I wanted to speak to you guys was Originally for the serverless summit kathy and I were going to do a tag team For a summary of what is the serverless working group been up to? Unfortunately, kathy is not going to be able to make it Now I I think this is only a 35 minute session. So I could technically do it on myself, but Is there somebody who'd like to To go tag team with me on this? Of course, my scott isn't on the call at one point. He may he may have Indicated some some desire to do that, but since he's not here Anybody here on the call want to join in that fun? Okay I don't know if I have the time honestly Okay, well, I don't I'm not I'm not asking because I'm trying to pressure somebody into it It's it's more I don't want someone to feel like they were excluded when they wanted to do something Like I said, I have no qualms doing it myself I think it's only a 35 minute session. So it's not exactly huge I'll refrain from now. Okay Okay, well, I'm not hearing anybody jump up and down But I'll do is I'll reach out to scott to see if he really wants to do it Honestly, I think he might be overloaded because he already has Others what he has doesn't have yeah, he's doing the intro there Then he has this serverless thing here and he may have other talking sessions there So he may be overloaded, but I'll reach out to scott and see if he wants to If not, I'll I guess I'll do it myself, but I'll let you guys know The reason I'm bringing this up now is I think by this friday, I mean tomorrow they wanted to have all speakers Names set in stone So what I was going to do is send them a note to make sure they have the list we have in here in their On their website. So we don't have to change it later on Okay All right. So now with that behind us, I'm gonna let you go Can you guys think of anything else relative to the coupon to you we need to discuss? Otherwise, we'll jump into the demo Okay, let's jump into the demo There it is So I think what we should do now is quickly discuss Some of the last minute changes that were made to the Jason that's flying around just to make sure we haven't busted anything relative to Doug's Schema Hold on a second. Well, if this is loading This doc is getting way too big Okay, so let's just start at the top here Okay, so here's the very latest um So I don't think last time we talked we talked about this ping and reset I wanted to talk about these and make sure you guys are okay with it because I'm they're a little bit funky, but they're more Procedural or set up ish. I'm not sure if the right word is So right now if someone registers with the system And something happens and they end up dying There's no way for the controller to know that they're gone And in particular It'd be nice if he did know so that he can reassign people to different jobs So for example, if a supplier goes away, we don't want a retailer waiting forever for him to get new cuts from that supplier. We want Some other supplier to take up that role and the only way for that to happen is for the controller to rebalance things out But he can't do that if he doesn't know somebody's gone So what I was going to suggest was that every 60 seconds Everybody who's playing in the game send a ping And if the controller does not get a ping from you within 90 seconds, he's going to assume you're gone And rebalance things appropriately If I'm not 100% sure that's eventing ish or not But I feel like we need something like that in order for the controller to maintain a usable demo going forward if you will come and go What do you guys think? okay, the other concern with this is This means you can't actually write a normal serverless function to do this work or Or you have to have something else like a cron job And I think that wakes your thing up and says send this ping every 60 seconds That that's the other part that had me a little bit worried was if someone wanted to write nothing but a pure function that scales down to zero When it's when he's not being asked to do anything He can't actually do that anymore. He has to keep something up to at least send a ping every 60 seconds Is that going to be a problem for anybody dude? Did you want to speak? Are you guys there? Can you guys hear me? Yes, okay You guys are like really really quiet today. You're killing me okay, I mean so Does this sound okay? I mean, I know it's not ideal, but I don't know how else to deal with these situations like jude, he's talking in slack so If we did turn it around though, how does the controller know That the other guy isn't there. Are you or are you assuming it'd be a request response ping? I was wondering if the controller sent a ping out to everybody, which obviously we can make that happen Are you assuming that the participant would have to send a reply back? Because Pings are typically one way right or all events are typically one way So we'd have to turn this into a request response kind of a thing and we'd have to use Rabbit mq for that purpose Okay, so How I don't know if you guys can hear that there are children running around here Okay, I agree with you that it's a lot's been scaled down to zero and then you have to come back up every minute or so whenever the guy sends a ping um it How long Because the ping goes to rabbit mq and it's not htp request response How long do you envision the controller waiting? I mean, do you think it's fair to say he has to get a response back within five seconds? Is that sufficient? I mean, I guess we could play with the timing, but is that kind of logic sufficient for here or is that going to be problematic? because things might be slow and in I'm not sure what I'm trying to say I'm okay with that Okay What do you guys think dug or or claus? What do you guys think about turning the ping around and making it in essence a request response through to rabbit mq but it and this is addressing um a concern that Can you run through that scenario again? What we're where this is why this is needed Right, so let's say there's a supplier out there who's supplying small coffee cups to some retailer What if that suppliers system goes down? Okay, so backing up so this supplier um Generated a connection event which the uh controller Um consumed and said okay, you're connected. So at some point that controller is distributing Offerings based upon what it knew at a point in time where the all the connected Systems and their roles right correct. Yes. Okay, and then and then An order is originated from an attendee acting as a passenger and that then starts these orchestrations of events and And so it'll go, you know from a retailer to fulfill that order and then If that retailers out of inventory then it's going to go to a supply supplier and then carry gets involved so you're saying that if that Supplier I guess for that retailer goes offline Then you have Those events Um that the retailer generated to replenish inventory not being acted on Correct. Yes. Okay And and the and so what you're saying is that if you if the controller knew that supplier went offline Then you would create That you send events that reflected a new event or a new offering Configuration so that another supplier that was still online would be able to handle those events that were already Issued but then how does that work? Because those events have already been broadcast From the retailer. How would that new supplier pick up those events? Right. So supplier pick it up. Yeah. So actually you you've kind of addressed two different problems and I only and my my solution only addresses the first half which is Okay, somebody went away and the controller needs to rebalance who's processing what type of orders I think the the ping thing works for that scenario, right? And as long as there isn't sort of a offer or a An order in flight it works just fine, right? But you're right the minute offer is sent if Somebody doesn't receive it to process it An order An order is sent. Yeah, sorry, but an order is sent if there's no one there to process it then You know unless that Unless that retailer resends the order you're right. We're screwed Um, I haven't thought about how to address that problem yet. Do you have a recommendation? Like maybe should People be prepared to resend events if they don't get a recent orders if they don't get acted upon Or should do you think the controller should step in here and take some action? Well, do you even think that's A real concern for a five-minute demo that that that is happening and Or are you looking at it more for Because you know, this would certainly be an issue if this was you know, something you were going to be Putting in place in real real world, but For a five-minute demo So okay, so I'm basing this upon previous experience with our other demos, which is You're right technically it's a five-minute demo We just make sure everybody's up and running and everything's fine People have used these demos for meetups or other types of events outside of the initial kubecon type of environment And I and I'm hoping people keep up their end points after the kubecon so that they can choose to show this In a meetup for example if they wanted to because we have people do that and that's why for example the mad libs demo is still up there Because people do occasionally use these things Got it And so as these things come and go I want people to have basically a running a working demo that they can use at any point in time so Jude you're talking about a timeout That definitely is possible but When the timeout happens Do you think the controller would rescind the offer or do you think it would Somehow tell the retailer to To to rescind it himself. How do you see the timeout playing out because what I'm actually also wondering about is whether If the controller had a timeout Then we probably don't need the ping Because they kind of serve the same purpose in a way Right. So if the controller noticed that an order was sent But a corresponding Action wasn't taken as a result of that he could assume that guy who was supposed to be processing is now dead and rebalance everything and then he could technically rescind um Yeah, so yeah, he could make the controller rescind he could send out the everything again after he does the rebalancing I like that because that that you're you have your inherent Ping or non ping from the the timeout. Yeah, I definitely like that solution better as well because it Other would also be completely serverless as well Let me think about that because that's a lot of work in the controller um But I guess he has all the information to know right? I mean he knows What supplier is supposed to pick it up? He knows what carrier is supposed to react to the supplier Okay, let me let me think about that my poor intern. Okay Okay, let me let me think about that. Let's see if it's possible. I think I know technically it's possible. It's just A fair amount of work. I need to figure out scheduling why so I can get that in there Okay, let me let me let me think about that one. Let me make a comment here I I mean, I think it would be easy for him to because he's putting the graphics on right so he's showing Uh All he has to do is look at his graphics and when an icon has been sitting, you know, if he's if he's tracking the time that You know a graphical element is sitting idle sitting in one place, right for too long then he's he's rerouting I don't I don't want to get into it but no it well Not not quite right so for example Well, okay, so let's let's walk through the scenario a retailer gets an order for a customer for small Or something happens the retailer says I need to order more cups and it has to be small He will he knows enough to put an icon on the screen that says this guy's ordered small It's a little bubble. Actually. Have you guys seen the latest? I guess I could show you that source I went to the He moved it again. It looks like Maybe well the source dog and source dog and soap up are the same thing. So don't worry too much about that um But oops, hold on a minute. Let me I need to bring in some controllers or some participants. Hold on guys my machine is like dying today. It's so slow Um, yeah Oh wait, sorry There we go. Okay. I love the dynamic nature of this thing. Okay, so Um, you guys can see that right? Okay, cool. Yes. Okay. Okay so I'm gonna place an order at One small so yes He knows enough to put up that little bubble um When he orders something small But he doesn't necessarily know that there's anything like Not moving per se Um And because in order for him to know that for example that a truck did not leave the warehouse He first has to know that the supplier got the request And there's no graphical aspect to that So that's why I'm not quite sure Doug. You're you're kind of about If in the in this um One that you went through in this flow if the If the if the supplier had disconnected Okay, where would this thing have stopped visually on the screen? It would have been here. Actually, I think I could actually force this. Oh, yeah, it would have been um The bubble that appeared here to the left with the small coffee cup would be sitting there and that would be It nothing else would happen on the screen Okay. Well, he must have In his his program Identified that bubble as an object, right where he knows where it's positioned. I would think and then if that had a timer associated with it, then Yeah Kind of yeah, well, no, I I'm sure I can make him figure it out. It's just I just need to work through it But the just let you guys know the way this happens is everything on here We tried our best to make it completely event-driven so that the controller was not Was as was as dumb as possible, which is I can't think the kind of way it should be so The reason the bubble appeared is because the retailer sent an event out saying he needs more cups That's why he did it. It's not because of any other reason like he didn't keep track of the number of cups for the retailer Okay, so he he tracked the event that went through rabid mq and that's why the event went up there um, so he doesn't have any sorts about Really anything else? So in order to make this happen, he now has to not only detect that event, but now as you said Start a timer that says, okay if I don't see an event coming from this supplier Um asking for that size coffee cup for this retailer After a certain amount of time, I need to take this supplier offline and we send that event Yeah, I mean if you look at it in real life If if all of these events were flowing through the three systems fine, right everything was connecting but but that supplier Did not act on it his system got got the event, but he didn't take action You know, you're not going to shut down your entire supply chain because he didn't take action So you you would need a mechanism that that at some point Allowed for rerouting an order like if a retailer ordered something from a supplier and he didn't deliver it in time He would need to reroute that order to another supplier Totally agree in a real world scenario. I totally agree Just didn't have the real world scenario in there yet, but yeah But maybe we need to make it out and that's fine This kind of sounds like what you're doing is just reflecting what could you know a real world exception, you know, we're Yeah, that's exception handling. So yeah, and that's fine. Okay. Um I can definitely do that or ask him to do that I'm not sure when it's going to get in there, but hopefully before Monday But okay, we can definitely do that and that that addresses the problem So we can probably look at killing this Which is fine Now this this next event here, I don't know whether we need this or not But the reason I added this was because I there were times when I wanted participants to Reset their environments um, and maybe this isn't necessary, but um in my setup I have it so that I can actually add new retailers new suppliers At will and granted I did this so I could test the system out, you know For example to make sure everything's dynamic. So as new retailers came on board this thing will grow um In our in our scenarios, maybe that's not an issue, right? Maybe everything's more static but I needed a reset in order to have the system tell everybody to Re-register themselves with the system Okay, by class Because one of the things that I noticed is If the controller recycles He doesn't necessarily keep track of who's involved and maybe that's the problem. Maybe he needs to But right now he doesn't keep track of anything About who's playing and this when he comes up He sends out a reset that has everybody to register And that tells us so anybody who was dynamically adding warehouses suppliers or controllers Just to make the environment more interesting to also reset those back down to their default value or their initial value And then what would trigger this? This is this is this is just the controller deciding to reset the environment for whatever reason Whether it's because he restarted or because someone wants to rerun the demo from the very beginning And they want a they they wanted a fresh environment. So technically anybody could send the reset event. That's just the controller So if if you had like you said outside the coupon demo You had others that just at any point time wanted to go up and and run through this demo If you had two separate groups running the demo at the same time Then what happens then yes, they may they stop they may stop on each other and luckily we never had that problem But but but see what's interesting is Depending on how you want to show the scenario, right? If you want to as you walk through it, you want to be able to show the connection message Well, if there's connection message only happens once And it was a month ago. You're never going to see it again without a reset Assuming everybody stayed connected the whole time, right? So that's the other thing is if you want to be able to reset the entire environment And be able to show the connections flows and stuff like that Then that that that works So then let me let me just show you what that looks like. Hold on a minute Let me show you an example Okay, so for example, watch this if I want to add another retailer, let's call it r1 Okay, so now another retailer got added And if this guy right here on the right and you can see the connection Right and that's all wonderful and good. So if someone wants to you know, really screw with the system Or not screw the system, but really show things being dynamic And they want to be able to show, you know, a whole bunch of Things coming and going they want to show the system rebalancing or whatever like that They could do some funky stuff like, you know start deleting retailers Right, and that's all well and good But at some point they may want to say, okay, I'm done screwing around and I want everybody to go back to the original state They can do a reset and everything goes back and that's What the reset message is you see right here It got sent I received it and therefore I reconnected everybody up I disconnected everybody who wasn't there and I had my five four five different connections two retailers two suppliers and one carrier and That makes sense to me, but who has control over that reset I think is important because you could have some somebody up there clicking reset All the time and blowing out the game for anybody that was trying to participate that is true, so So at a minimum The only people that would ever know about the reset are the same people who have access to the queue Which are the people who have the user ID and password to the queue which are only us, right? So it's not like any random person can do a reset or actually do anything with this So that that part's a little bit secure The only Concern we have is what you were talking about, which is what if two people are running the demo at the same time? well Why things disappear that's kind of funky Well, I just think you send That they that you would put on the ui that the game is being reset Yeah, we could do something like that or what we've done in the past is also people Told the group when they were using it then just to make sure no one was screwed without time That's another thing I'm less worried about that to be honest, but I think I think the reset's important. Okay Okay, I'll I'll like I said I'll keep that in there Why did everything get pulled away? Weird, okay. I'll have to look into that. Okay, so I'll keep this for right now So jude, I'm not sure I understand your question 100% reset doesn't involve the controller as well It does involve the controller the controller forgets everything and forces every it requires everybody to re-register if that's what you mean Which is why in my case I had a reset in the connection messages Yes, I agree after a reset everybody needs to reset their connection. Otherwise the controller will assume they're not there Okay, good. Yes Okay, um in that case, let's scroll down and see where anything's changed I think I made one change and unfortunately, I don't think I had change control on it. So let me see if I can find it and then Okay, it may have been Here we may I may have this may have been it. I think originally we had here We had order in both places meaning when the Customer placed in order and when the retailer placed in order I couldn't tell the difference between the two They were I'm not quite sure why I couldn't tell the difference Actually, no, I think about it because this one has provider But there was some reason I couldn't tell the difference between them or maybe it was when I think I think what had happened is in our last call We talked about changing source for the passenger order from being Uh saying passenger to saying retailer. So that was you know and you know, I said I didn't didn't bother me but then when you went to to Implement that and then you found the problem. So you to distinguish between the two It Yes, I right. I I would much prefer it to be the type to just remain order On both cases and then use source to differentiate Yeah, again because that way you're keeping in line with the the class structure of you know schema.org and with the airport's Scanty model, right? I think there's no difference in that If there's one concept called order with one set of attributes and yeah, and so Anyway, if you if you could do that that just put it back the way it was I think So change this back to change this back to the service or passenger. Yeah, right So Jude, would you be okay with that? Okay, so I'll make a note of that Okay, and then order you know the dot customer dot Oh Pow Okay, um Now Jude you or you put this here Did you need that for some sort of disambiguation or was there another reason you needed that? Okay But it sounds like Doug you're saying that breaks the model it breaks the model. Are you okay with removing that Jude? okay So well, I can't do that. Okay, so Okay, good Okay, so we'll kill that one So order Okay, and this one down here Um, I think that makes sense to try to think I want to make sure we actually got up above So we should probably add it here as well, shouldn't we Jude? But you had you had small in the subject. Oh, you're right. That's where you didn't need it again Oh, okay, so so the subject. That's a good point. So Jude. Why do you think we need this here? Oh, wait, what do you see over here? Hold on a minute. Gosh, I wish this thing would scroll interesting So Doug you have any reaction to that? um You know, uh, go go back to where you're defining the original offer Do you mean when the controller sends it out? So then, okay For controller to okay, so here's one going to a retailer. Yeah Okay, so you had sort you had uh Type as an offer product and then you had in the data you had offer small medium large So I guess to be consistent with this, um It down Below your source would be if your type would be offer dot product Right and and then you would put in Well, hold on. Let me just paste them side by side so we can see them right Because these should be the same Uh Well, you have subject supplier there. So we didn't really pick the one from the retailer, but the retailer has a similar one True. Uh, well, let me just double check. Let me just save it for me just so we're consistent Right there I think. No, I'm sorry go up more Subject that supplier Carrier here is it that's a connection darn it. Where is it? No, we don't have one for the retailer We don't because we don't tell the retailer what he orders or what he offers he offer everybody offers small medium large. That's why Okay, so it's a new Okay, so go go go back to what, um What you wanted to do because I don't think it matters. I mean, I think if you put if it's just putting offer or uh Small The subject in that case Okay I Again, we're we're kind of Creating a hybrid here. Anyway, so it as long as the type is offer. Um, like In it You could put size in, you know in the data if that helps And then and then just remove and subject becomes I guess irrelevant at that point Yeah, that that's gonna my question. So jude if we did that What would subject be in this case? Oh, okay, we can remove it But from a um From a pub sub perspective, isn't it easier to react to type source and subject? Where that's matching for a retailer And not have to get into the the data to find that I don't know No, you have to anyways because you got to get inventory level Well, you are well, but well, it's a couple things are one. I think you are correct. However um There's nothing that says a cloud event can't have data in the data in the data section as well as in the headers And that's perfectly allowable. In fact, we actually recommend it because cloud events should not be Why don't you just leave it in both places that way? Okay, you're showing there's flexibility there to Okay, I don't I don't I don't have a problem with that. However Does this mean that? well then Inventory level let's search back up That means we should probably include it here as well for consistency, right? Right? oops It was size colon small, right? right Small s. Yeah, okay. So let me just make sure Okay, so then we do that And that's the previous flow. So, okay. I think I don't think that's an issue Okay, I think that's it then Okay, um Does everything still seem okay to you guys well flow wise? I think it's amazing that it all came together Well, we're not done yet wait wait till other people get involved. I'm sure they'll find this So, okay, yeah, but I think I think answer right now as long as we have Uh the ability to uniquely identify each event and know it's specifically who it's for and what its purpose in life is And we don't get ambiguity like we had for a minute there. I think we're good that that's my biggest concern so okay, um in that case, uh I'll take the action to Try to get the intern to make the controller smarter relative to people coming and going um And I think that's it then other than Maybe next monday Formally telling everybody to start coding Okay, so, um if I was to share this work to at this point I those uh the um URLs to the the two parts of the of the the ui are or um That they're right there, right? That's not moving and that those are always up at this point Or they get shut down Okay, so they are not moving Uh stability of them is a little questionable. It depends on how I leave things. I I'm trying my best to keep it up um The I can't guarantee they're up 24 seven yet by the time I best to keep them up as much as I can so yes I just can't guarantee it. Okay, and then and then the All this you didn't go right with all the microservices and Where is that available? So yeah, I'll double check with the intern to make sure he's comfortable with exposing the controller logic Um, I don't know the controller doesn't even it's more about what would be implemented by the I was afraid you're gonna say that. Okay. Um Give me a give me a couple more days to fix that I I I did something kind of hacky because everything's in one gigantic executable right now I didn't have separate microservices for things. It was just easier for me to manage it that way I do want to break it up So give me give me a little bit of time to split it up. So it actually looks a little prettier Okay, so the urls is this one here and what what's the other one? The other one is just a airport without the slash of you without the view The airport without the view should take you to What people will do on their phone Okay, and just so you know, I'm not telling anybody outside of our little group In order to get this little pop-up down here So you can actually simulate a phone on the screen without actually pulling out your phone Just hit control p It shows it and hides it That way you can run the demo without having to get out your phone Makes sense. Okay. So just do a control p on this screen. Yes, and it'll bring that up. Yep. Got it. Okay. Okay It's really freaky that things start disappearing Okay, I'll work on that. There must be some messages getting lost in translation Okay, I'll call Jude. I'm glad you can get it up and running. Um, let me ask you a question Do you guys have any experience with rabid mq? the reason I'm asking okay, the reason I'm asking is because Um, I'm actually running rabid mq inside of docker container And it was up for Okay I have a doctor container and it was running for days and everything was fine and then all of a sudden it crashed And it gave me an error that indicated to me and ran out of memory Which to me says it's keeping these events In memory someplace and it's not dry. It's not deleting them as people pull them off the cues so It's interesting that uh, you just mentioned redis because that um There's another implementation very similar to this that used um Redis Uh Rabbit mq was chosen because somebody had suggested it, right? Yeah, there's no hard requirement. I mean, if there's a better choice I think we could switch. I was gonna contact redis if they wanted to participate in this So is redis just a pub subsystem? I've never actually used it. No, it's a events um It's what used can be used for event sourcing Um and in memory, uh, persistent, you know, persistence of um these events And so it has its own it has a way to Yeah, they have a new streaming Uh component I guess that was released just this year that is probably pretty relevant to this but again I was just going to go contact them The lf edge Projects like edge x is including redis and what they're doing. Um So anyway, I was just gonna say if that what they What they thought about this so the events will people persist once consume which actually I like however Can you have multiple subscribers? receiving the same event Okay, the answer is no, then that's a problem, right because we want multiple people to receive the events So I think that's a problem With redis you're talking about. Yeah, according to what you just saying. Yeah, okay So we need something that allows one event to get fanned out to multiple people I just need to figure out how to make redis not redis rabbit mq delete them after everybody's received it Otherwise, I need to recycle rabbit up here. We know and then because it runs out of memory so But anyway, that's my problem As a timeout Need for how long it sits in in memory Oh If you can give me that timeout, I'll do that because if I set the timeout to be like a minute that should be more than enough time So point me to some documentation for that. I'll all right. I'll look as well. So that'd be cool. Thank you I'll give a sec. But in the meantime Uh, there you go. Hold on a second I like that interesting So, okay, that's one thing I don't actually do Is I don't have a config file Or maybe I should start looking into that um, I just basically bring up a rabbit mq docker image and Use the rabbit mq cli just to add a user Um, but maybe I need to just look at config files Uh, hold on a minute Oh Okay, well, I don't we don't need to take up your time. I can I can basically get this offline But this is basically something to look at Okay, cool. Okay. Now anything else you guys want to talk about? Oh, that's good Doug. Yep Yeah, look it's looking more and more like an airport. I think there are a couple little minor tweaks But it's it's it's getting closer to look like an airport Kind of funny, um Redis does pub sub but what does that mean? Okay, does does it do fan out is the question? Hold on Oh fan out So what would be the advantage to using redis over rabbit mq? I I would say I'd rather get a redis representative involved and Let them see how they would handle this, you know Interesting So how I'm assuming it's It's it's still a pull model just like rabbit mq, right? Redis is all about in memory No, what I meant is how do people get the events? I'm assuming they have to sort of initiate a connection to Redis and then events start flowing. It's not like redis opens a connection to the client or to the receiver, right? Will be pushed by redis to all the subscribed clients And I'm assuming I'm assuming it's similar to rabbit mq though, right? It's a persistent connection and after connection gets dropped and you reconnect You won't lose events during that downtime, right? They'll just sit there in the queue Is that right Jude? They'll just sit in the queue until the person reconnects Okay, see that That might be okay actually because I don't even think in rabbit mq. It does that at least not I haven't noticed that Yeah, there we go. So I'm no I've heard no worse off Okay Okay, I'll take a look at this. I'm because I'm assuming switching between rabbit mq and redis from the implementation perspective There's not a huge change just switching out which library you call and stuff like that Okay Um I'll I'll post what I The implement it. There's there's learning.com that implemented Very similar Use of eventing That that's showing, uh, you know commerce Um, and they used redis and so I'll just send you that link because it You know and this kind of image I I almost want them to participate in this Yeah, yeah, no if we can get if we get you know cost redis's name in there. It has a participant that That's cool. Yeah, and that at the end user learning.com. But yeah, um You should be able to kind of I hope rabbit mq will work and then you don't have to worry about switching things out last minute Well, we we we kind of need to decide right It's up to you guys because I have no opinion on this whatsoever. I'm not what it's jude prefer Yeah, jude, which would you like? redis Okay, is that okay with you dug? I don't yeah Because it works. I don't give a crap. Well, but but if you give all this to jude what you've got and since he knows it Right and you could that's true. Do a redis implementation of what you've got Yeah, and that is true and if it doesn't work and redis doesn't work for us we get to blame jude So as long as I'm going to put the finger at I'm I'm happy Because that's what life is all about having someone to blame Okay, well, I'll take a look at that and see what it would take From the controller side to switch things out As I said, I can't imagine it's a big deal because the transport mechanism getting these things back and forth should be fairly lightweight Okay, so I'll start playing with that Code is easier by the way. Yeah, so you say, okay We'll play with it Actually, to be honest, I didn't use the s actually I didn't use as well. I did use a go line SDK, I guess, but I don't it didn't seem that painful to me But I just followed blindly some instructions. So Anyway, I think we're wrapping up here besides that I'm getting really hungry for lunch All right, so there's a Monday call then on this Yeah, hopefully hopefully on Monday we'll be able to say Start coding it would be good to go. Okay. Okay. All right. All right. Cool. Thanks guys. Bye