Hey Tommy. Hi David. Hello. Good morning. How you doing? I'm doing well though. Thank you. How are you? Good. I'm probably going to regret suggesting these three hour meetings because it's like for me it's 11 to 2 which completely kills any chance of eating lunch at a reasonable hour and I'm going to be starving and snippy by the end of it. I forget half the people here or a good portion of the people here are East Coast or in Lavamer and then EU too if I understand it correctly. Yeah, fair number. Yeah. I thought it was 7 a.m. Pacific. I got up at 6.30 and I was like oh in fact it's at 8. That's actually one of the reasons I picked this time though is I figured 8 a.m. isn't too bad for West Coast folks and the folks in Europe should be happy. Hey John. I'm in California. You live with the sun. The sun is getting up around 6.30 right now. Yeah. Hi Doug. Hey John. And that was Klaus on there too? Yes I'm here. I do. So the real question is is Clemens going to remember because I really wanted to pick on him because he had the most to say about just even the first example so he better show up. Hey Scott. Scott you there? Scott you may be having mic issues because I couldn't hear you when you came up with me for a second. Oh I'm having mic issues. So while we're waiting what I was thinking about doing and see if you guys are okay with this was I was going to jump right into sort of the design discussions and continue our chat on this sort of walkthrough. And then at the top of the hour, I was then going to return to the normal agenda just to cover some of the high level things are not going to hurt them things. Normal governance types things for those people who could only make the normal hour, and then go back to the deep dive and then at the top of the next hour, if we have any SDK topic so I think we have at least one. And we'll jump over to SDK and then return back to the deep dive. That way people who can only make the normal schedule calls won't feel like they missed out. Does that seem fair? Sounds good. Cool. Whoops. All right, three after. Let me go ahead and get started. Oh, there's, I believe, Lou's last name is dang. Hold on a second. Hey, Lou, you there? Yeah, yes. Okay, cool. All right, why don't I go ahead and get started. Hopefully other people will join as we go. It's unfortunate Clemens isn't here yet. Oh, hey, Vod. Because he had a he let's stay on this one but it seems to me that there really wasn't any objection to us supporting the, what's the phrase we're using for it, the aggregation model. And so therefore, being able to filter on things like source as opposed to it just being something that's sort of outside the event. It sounds like that's something that people did want to do. So do you guys agree that that source should just be another filter property that people can filter on? Yes, okay. But I think Clemens might say no. That's why I was really hoping he'd be here because I know he had some opinions about this. But, okay. But for now, no one else in the call has any concerns with that, right. Okay, so then, um, I guess my overall question for the group is as I was putting together this example. The biggest thing to me was the fact that I chose to make the specification of these properties to be configuration things as opposed to filters. And if you remember correctly, I did that because I wanted an implementation of this on GitHub to be as small as possible and requires a little work as possible. And as I said, I didn't think that they necessarily use filters per se. I mean, I don't know what they do under the covers. But the fact that they sort of have the user pass them in as individual properties seemed like a natural thing for me to model it this way. And so my question for you guys is not, is this the right thing to do because I think people can make that choice themselves in terms of how they want to model these things. My question is, should this spec allow this choice? Do you guys have any opinion on that? I'm okay with the freedom. I think it should be implementation choice. Okay. Thank you. Anybody else want to chime in. Okay, so in that case, the results of that to me was in the spec today, we actually don't allow the filter to be optional in terms of the subscription manager. I believe has to support the filter mechanism and in particular the simple filter dialect or filter type whatever it's called. But it seems to me if someone chooses to model things this way, I don't think we can force them to support filters at all. In other words, my net of this is I think filters should be optional to support. And therefore I think we need a way to advertise in the discovery spec whether the subscription manager supports any filtering at all, and in particular be able to advertise that they don't. The exact mechanism by which you do that I haven't decided yet, but I wanted to see what you guys thought about that decision. We both be honest. Because I don't think that's because you have the basically config solving part of the filter that you should not have filtering, but you can make it optional or not. And that was my point right I think I was uncomfortable with the idea of forcing my implementation of the GitHub subscription manager to have to support filtering, because that that actually could be a fair amount of work. And I did not want to force people to do that if they didn't want to. Yeah, I agree. I think the filtering is the biggest amount of work in the whole subscription model. Okay, thank you. Everybody else who's kind of quiet any thoughts on that any disagreement with the idea of making it optional for to declare optional for subscription managers to support. Okay, not hearing anybody. Were you asking me beforehand that optional versus removing. I was, no, I wasn't no, I wasn't proposing to remove the filter at all I was just saying subscription managers are do not have to support it. Okay, that's fine. Thank you. Yep. Okay. Okay, in that case, before I move on to the next sort of step in my thought process here. Is there anything about this one that people want to talk about that I didn't mention that may come as a surprise to you. Yeah, go ahead. Yeah, I'm still thinking and trying to adjust that. So, we said that sources also just another filter is that or can be filtered upon. I think source. Yes, but in other words source would just be like any other cloud of an attribute where if the if the suggestion manager supported filters you could filter on source yes. Okay. In general, I like that idea but I just wonder if we make either filters or config I mean if we both make both of them more or less optional. How in the end this would work if I have something like an aggregator that passes on subscriptions upstream. There's not much in the in them anymore that helps routing those subscriptions upstream and the values in config are more or less proprietary in the end. Yeah, I apologize. I did mention this the first time we look at this document. I think what it does is it makes the metadata or the discovery spec information more important than ever. Right. So the users. So somehow we need to make it perfectly clear in there that for this particular subscription or this particular service. Here's the config options. And whether it supports filtering or not, and you have to very clearly understand what the config options are for, whether they're simply to configure things or whether they do some sort of implicit filtering. And I, I don't I think that's the tricks we have to go. But I think I kind of agree with what I think you're saying which is, it makes it a little bit awkward, and not as programmable. You have the human involved to understand what's going on. But I don't know what else to do about it to be honest. It's just the subscription does not contain now reference to a source or a service anymore. But yes, the config values and I'm wondering if that's still possible. I mean, if that really can then support interoperability. So hold on a minute. Let's go back over here for a second. I want to make sure understand what you're saying. So I think in discovery, we have this notion of a service, right? Yeah, hold on, let me bring up the discovery specs to make sure the same thing. Okay, we got this right here. Okay. So I imagine that for a service we could describe then those config values, those properties. Yes, that's right here. Okay, yeah, exactly. Yes. So if now in the subscription, I could have this relation to a service or a source, then it would be possible for a subscription manager to create that relation. But if I don't have that, and it contains these config values, it's getting hard. So Clemens, I'm glad you joined us. That's just back up a second here. So Clemens, I know you were concerned about the whole aspect of the source related to this stuff right here. And before you joined, we were talking about not whether this is the right choice or not, meaning I chose to model the specification of these properties as a config thing as opposed to a filter. And so the question wasn't whether that was the right model, but whether it's an allowable model per the spec. And no one disagreed that it should be allowable, right? Because someone may choose to not really want to support filters at all. They may just want to say, hey, here's some interesting attributes and I'm going to use that to know what events to send you, but they don't necessarily think of it as a filter per se. So there were sort of two decisions we made. One was, this is legal per the spec, whether it's preferred or not different discussion, but it's legal. And the other decision was that would imply then that filtering support by the subscription manager should be optional. Because today in the spec, it doesn't come right out and say it, but I think it's strongly implied that the subscription manager has to support at least the simple filtering dialect. And we kind of agreed that no, we should make that optional because filtering is, could be potentially very expensive for somebody and they may not want to support that. Any comments on that? Yes, I can see that on config, whether config is, is, is how we want to go and set context. So context for the subscription is something that I'm, that I continue to be on the fence on the fence for so that the conflict here was for, in my mind for configuring that context, but not for identifying it. With config, I would, I would tell a subscription source that I want to have a notification every minute. And so the, the, the, the, the notification interval would be that's something I would set here. I think that identifying that source is something that I would prefer to do elsewhere. Yeah, I understand your desire, but that's not quite the same thing as whether the spec tries to put lines in there that outright bans it. Right. Yeah, for, but for semantic clarity. I think, I think we need to have a, we need to have a way to identify what, what to correlate to the source and to then configure what that sources ought to do in order to give you events. I think those things are different, but, but I would like for the source that we are encoding an events to be somewhat correlated in some way to how we subscribe. Because ultimately, we're subscribing to events from the source and expressing that through the config seems a little odd. Understood. And I understand that it's odd.  Yeah, it's just, I don't know how much you always refer to the source, like if it was the only thing that matters. Why, for me, when I consume events, I will say that the only thing that I really care is the type of event. Yeah, but that's, that's true if you, if you're not dealing with multiple sources in the same, in the same context. My vision is like when I take the GitHub sample is like as an external company, I will care when someone push on our repository. I don't care from which source because it's already coming from GitHub. So whatever the source attribute is. I was not expecting to filter on that. I would say, okay, like, it's because the event type I think that maybe I'm wrong. And if I remember correctly, I would have defined like a push on a repository like a com dot it up dot repository dot push as the event type. No, sorry. Yeah, so I think you're, you're, you're, you're mapping too much onto the onto the event type the event type is not scope to is typically not scope to a particular resource. The event type is typically generic and then you get the extra scoping from the source so there is a, there's one type that tells you that the file has changed. So, I'll, I'll, I'll refer to something that exists in our world and that is Microsoft storage dot block created. That is one type that exists for all the, all the, the, the, the storage change events in all of Azure, and it's being raised a million times a second.  Okay, isn't the choice of implementation or you think that should be like basic implementation that they were on for exactly the same. For me it wasn't clearing the specification, I guess. So our, the event types are fairly are are described as being the specific type of events I don't think they're they're referred to as being something that gives you scoping for for an object. I would be also overly specific because then you would literally have to go and create a new type for every storage account that you want to go and deal with or for every repository that you want to go and deal with. And so that makes generic applications, but different difficult. Tell a little bit like we might be going in circles. Yeah, but that's, so there's, there's nothing wrong. So I don't have any, I don't oppose using conflict here. It's just that I'm, I wonder how we, what we need to solve is how this, what the scoping is, and how the scope result relates to where the event comes from. So when we go back to the event, the event has two elements that that provides scoping. One is the source and the second is the subject. And the source tells you clearly where that event comes from. So my expectation is that we have some way of correlating the subscription manager to what that sources, either by having a parameter that tells the subscription manager. It can help me subscribing events from the source, or by having the source itself expose a subscription API. And the first option you mentioned there, are you. It sounds like you're almost. I'm not sure whether you're suggesting that source should be some sort of top level thing here, or whether we just need to make sure people understand. There's no source inside of filters. Yeah, so I think I think the source is a top level thing here for subscription managers which can, which have a scope that spans very many different sources. And then it could also be implied or be null. If you're speaking about the subscription manager itself effectively about its own scope. So just just to make that concrete. And I'm going to stick to that to that to the block account because the storage the storage thing and block credit is pretty clear. I am. I'm actually trying to model this right now in my intro of coding I just got stuck this week and so I couldn't couldn't make as much progress as I wanted to. So I'm just playing now with two approaches one is to create a subscriptions endpoint, literally underneath the block account, or actually underneath the container, so that you have this, the longer I that identifies the block of subscriptions. So you can go and walk up there and go and subscribe, and then that the sources implied, or, and this is something and that's something we do today is you walk up to event grid. You do a, you do a subscription subscribe gesture, and then a parameter intercept subscribe gesture is the, is the, the, the address of the thing that you want to subscribe on which means that is the, the, the address of that, of that block container, which is a very long The upside of the latter approach is that you can go and generically have one thing that's identifiable and has an endpoint and you talk to it. And then you pass it as a parameter. The upside of the first approach which means you're putting that endpoint right on to the object is that discover abilities better. If you're looking at the blog account and its API, then putting a subscription endpoint there makes it obvious that there is an operation for how you can get to events from that thing. Versus having a subscription manager and live somewhere else, where you then have to go and literally know about the relationship between the two that's the that's the tension between those two models. Have I closed your hands up. Yeah, so I understand that example for the blob store but that's, that's, I think you're sometimes also using examples from IOT so how would that work if a sensor is a source and you have hundreds of them, you then have to create a subscription per sensor. You would. Hey, so good. That's a great question. You would, you would, you would literally subscribe, you would probably subscribe to the street. Someone needs to go and consolidate those events for you. If you want to have events from 300 individual devices out of 900. You have to go and turn those subscriptions on or off individually, or you care about the entirety of those and then, and then we're talking about individual subscriptions, which means you haven't you haven't a subscription manager, and the subscription manager, you passed that the, the, the, you passed that device, the URI of that device the identifier to the subscription manager as parameter in that case and then you are directing events from that device into your direction. If you are interested in events from all of those devices then you might be subscribing to an aggregator, which is doing that job for you already in an actual system. Yes, so if you have 900 devices you want to have to have events from 300 of them. You have to have a place.  That means that you are only interested in 300. Or you have a you individually, you have individual subscriptions on them. But I don't think I don't think you get around, you get around having either subscribing to an aggregator, and then getting alerts that are derivatives of that stream. But that no longer means you're subscribing to devices you're actually subscribing to alerts that are produced out of the aggregation. Or that you are really going to wherever those, those, those events land in your infrastructure and then individually being interested in that device or that device and that device that means you have literally the subscription per device. Except you could, you could also aggregate and propagate up the subscriptions from the aggregator. So like if you try to apply of producing events, filtering events out as far up the producer chain as possible, you could have an aggregator that accepts these kind of wildcard events. It understands the things that are connected to it, and it can propagate subscriptions up as, you know, the filters become loosened. That's, that's a great optimization. Right. Yeah, this is just a detail that can be hidden from the initial subscription request, right. Yes. So, so if you're really if we if we are going down the. So, so what you're what you're saying is something that I've heard a lot so far kind of in theory but I haven't seen much yet. So what is, for instance, this whole notion of 5G for deployed in the network smart routers that can deal with application level constructs, so that you could go and and say, you know, I know this device is attached to this 5G node. I'm going to go and subscribe through that intermediary to events from that device and then you have some you can go and optimize and how you go and do the distribution of the flow and the filtering and all those things that I mean there's lots of future potential there. But I just don't see that yet. So, where we go with this Clemens because I think I think sources of primary year. But, but if we if we okay. I think we're suggesting is this right. Now if we do that, I'm not sure what that means, because if you only have a single source behind this event stream. Okay, it's not that makes sense.  What does it mean to fill this in.  Well, if you're, if you're not. And just proxy because then you can have a different security context. And if you interrupt the ability with different company, basically when I connect to GitHub, I need to have my Github tokens. Why basically when I forwarded to my own customer. I want them to have I don't know and another company token that is different from the Github token so and I don't want to rework everything. Yeah, I guess I just I'm just confused Clemens because I think in the, what I want to call the simple case where you have a single source behind the subscription manager and the source of value is going to be the same for all events I understand that use case. Then you leave that off that because then you don't need this and we have two cases we have one, we have one where the subscription API is on the source. In that case, that parameter you can omit that because it's not right. We're talking to the thing itself. Right. I don't need that. But if if this acts as a as an intermediate as an intermediary, which means it is a subscription manager which looks down at a multiplex stream of stuff. And you are interested in in the events from a particular source then you would go and specify that. Right and that's when I start getting confused because at that point I'm wondering. I think we're all in agreement that the source value in this stream of events coming from this one subscription in some cases may be the same value every single time. Or inside that's more like an aggregation case that actually could change his value over time depending on who actually generated the event. So it seems to me you need to be able to support both static value and the changing value. And at that point I'm wondering why isn't that just a property inside the filter. Because because because because because because the source here actually does work it activates something. If you put it in a filter, then you are assuming that the events from that from that source already coming. But you also need to keep track of what you are interested in, so that you can tell if you need to the source. Hey, start giving me events. And because in our surface event grid. If all the storage accounts that exists in Azure for with all the containers. And we're talking about trillions of objects. If every single one of them were throwing events up into our system. Without having been having been asked to go and start doing that, then the system would just be swummed in I don't know how many trillions of events every second.  So that is far rather impractical. So, so we need to we need to keep track of, of, is there actually interest in events from that source and we can go and activate the event admission. And when the, when the interest goes away when the subscription is being deleted in the last subscription effectively for that particular object is gone, then we also stop, stop emitting those events again. So that's the, so, so, so it's not just a filter because the filter assumes that the events already coming is simply, and you're simply picking something out, but making the source explicit here also gives you a way to keep track of what you have of what you have subscribed to. Okay, that helps me. That's actually implied. Excuse me. I mean that that semantic is actually implied. So, a filter could be proactively applied. It seems to me it doesn't require that it doesn't require that the events are showing up in your environment, or to are actually being delivered, you could proactively push the filter out to a series of sources that you're aggregating from. But doesn't filter doesn't filter just imply that it's constraining. Certainly. Now, so the, the constraint the question is, I think there's multiple times at which you can do the constraining. So, you the aggregator can know whether a certain source can do constraining in real time. But also, there's some like, you know, take your your blob storage example. You know, maybe I would think that the default event, or the default case if I don't supply blob that I want to my source is that I would get all public and potentially, and although you could maybe make that more of an opt in but anyway, I would get all events in my subscription scope, all of the things that I probably have access to all events come to me if I don't supply any filter. That's what I would expect. I wouldn't expect to have to explicitly declare this one and this one and this one and this one, everything I have. Oh, by the way, those are dynamically created sometimes so therefore I'm going to be missing. And my, and my perspective is, is, I actually want you to go and opt in, because I want to avoid that extra traffic. I completely appreciate that you do. I think that you could, you could manage that internally. I mean, there's nothing to say that the node that you're you're issuing the subscription to has to be the node that performs the delivery. Even the same system right and nodes. And it's practically. That's practically also not in our in our case. Right yeah it's you're just not going to be able to do that there's there's too much. And it would cause architectural problems. It would choke off the flow. Yes, but so you're going to have a more complicated implementation behind the scenes that's going to be the subscription API is going to facilitate kind of propagating knowing the details of all of the sources that can potentially produce the events that you're there being subscribed to and pushing this subscription to those places. So you're saying that, so I shall infer the candidates who might, who might be who might be requested to go and admit events from the filter. I think that that's a potential need, particularly for your advanced case. What do I do if you tell me if the filter is simply saying true everything. Well that person that that whatever endpoint is configured is going to be inundated. But it might be a valid thing maybe what I want to do is do something like archive everything archive all activity in my account some for some kind of an auditing purpose. Okay, so, great. So how do we how do we specify your account. Well as the subscription provider, you, I would hope you would require me to identify myself and that provides a security context. That's why I was talking earlier about the public publicly available things. And then also what I as with the security context I bring in the loud. The security context is so when I go to the security context. So when I look into the Azure portal. I have, I don't know, 40 different subscriptions that I have access to. Yeah, and each subscription is obviously a separate Azure tenant. It seems like in that context it would be totally reasonable to filter on subscription. Yeah, but then then already so my security content is not sufficient. That's what I'm saying. Which means, which means it's sufficient to what is accessible to the subscriber. Now, as a subscriber, and as an implementer of the subscription API, you might want to require subscription is a filter. You might want to require sources of filter. Okay, so that would be part of your contract with your particular users is that the semantics of your implementation requires these filters. And if you don't supply them they get back in there. How does that then how does that. Okay, so, so if we don't want to provide any scoping whatsoever in the subscriptions gesture. How do I know that a sore that a an event that I'm getting has been delivered by based on a particular subscription. Like how do we find out the cause of effect. You're talking about basically like some sort of subscription ID kind of thing that has to flow along with every single event. Yeah, I mean, if I if I if I have an if I have a subscription API which is clearly associated with the source. Then I know when I get an event and the source is filled out where they came from. So if I have a subscription and I do this on a particular container, then, and I get an event that I know that I have the where they came from. I can also I can also make sure that the combination of destination. And so if I do push delivery that the destination of source and target is unique within the system so I don't deliver double. So, so I think we need let's go to the queue because I know some people have been waiting so Scott then Remy and then I'll go Scott you're first. Sorry, I should have brought this up much earlier but I know we're talking about this imperative API but like anyone have any hearts to throw the entire thing out and kind of move to a resource model. Can you elaborate on what that means. Can. What if we described instead of this, the current API that we've been kind of working on. What if it was declarative. Right. Kind of Kubernetes resource based. Doesn't mean that it has to be in Kubernetes but the thing that would implement the API would speak similar API to what Kubernetes does. Oh, but we need we still need to have a we still need to have a wire a wire protocol. Yeah, it's HTTP rest. I mean this is HTTP rest. Yeah, but it's not. It's a very imperative API. And if we go this direction there's always going to have to be this adapter layer where clouds will have to consume this imperative API and then translate it into some declarative API and then translate it back to imperative. My world, my world is very far away from the declarative API world. Yeah, but that's where the future of APIs are going. Well, that's that that that that that might be true in in your bubble it's not true in my book. I guess I guess I'm not sure I understand the difference to be honest it seems to me in both worlds you still have to specify the same information that we're talking about here don't we scar. It solves this problem of, do I have to specify the source or not because in the declarative model, it could be understood that the source gets, you know, gets resulted in the status or there's some mechanism that's constantly updating based on other information that's available to it. But you still have relationships I mean ultimately the declarative model is like if I look at Kubernetes.  But you also get the reconciliation and the feedback. Yeah, but then, then we still need to go and establish we still need to establish a subscription that will stably deliver events to you somehow. And how do we establish that. The stable parts the stable parts the piece that's in question right like maybe the value prop is as I add new buckets to my very very wide open subscription. I also get those new bucket events, because that's what I subscribe to. But that's just a scope. Right you have a scope and at that scope you can still, if you are getting extra events if you're adding extra stuff underneath it. But that's fine. Like if you if you if I go back to the to the storage account, if you subscribe at the container level and you add extra directories and inside those directories you add files you also get to get events for those files. Yes. Okay, I said my piece. It may be useful if maybe you can write up an example and explain how things would change because like I said, I personally don't understand how it changes anything. Because even in K native when you set up a subscription or an event source, sorry. Or something like a broker right where it has filters and stuff like that. It looks the same to me as this. So I'm not sure I understand the difference. For example of how our world would change differently or change radically if we turned it into a declarative model, because to me this is declarative. Okay. But maybe I'm confused and it won't be the first time. Okay, for me your hands up. Based on what Clement said and what you just updated on the document. I do agree with you is it seems that the source is a configuration value in the scope of Asia, but should not be like for enforced by the protocol. So I really like what you just did. I guess it was your point. I need to speak up there. You're trying to you're trying to steal my thunder. Yeah, actually, what I was going to say was thank you Clemens very much for your for your description before because that really helped me solidify in terms of what you're thinking it just it was alluding me for some reason. And now I have some clarity and that's why I put it down here because I realized that when you were talking about needing a source as a first class thing, because you need to know which thing to turn on the events or go, you know, which thing to go talk to to turn on the events. And I realized that's exactly what these two things are doing. In essence, right, they are describing the source it's just not calling it source, right. Um, and that that's why I moved it down to here because I realized that you may or may not want to do that and it does become sort of a configuration option kind of thing. I mean, it's top level around here. We can just we can discuss that but the one thing about this that I thought was interesting was later on during my ramblings at the very, very end. I, I thought, okay, if someone does support filtering, they could have technically expressed the entire subscription this way. And the owner and repo, which basically the source are part of the filter dialects and I think this may be what Eric was leading to which is, it's the subscription manager's job to look at this and say, oh, you know what, I'm going to have to extract this information and go talk to this particular source and tell him to go turn on as an end stream. I think that's what Eric was saying or part of what you're saying. And is that, is that right Eric. Yeah, that's fine. Okay. And if that's true, I do think that it's a completely valid choice. But I'm not sure I want to force that on everybody either because that's also a very expensive choice. Right. Especially if you're living in I think Clemens your world which is filtering is simply a filter and nothing more right filter for me filter for me is I have an event and then making the decision of whether I want to deliver it. Exactly. Right. I'm not necessarily sure where I'm going with this other than I'm getting a little more clarity now and that's why I think if I was to sort of try to summarize where I think my head is going is that source should be a config thing. But it should be optional. And I think the discovery metadata for this particular subscription manager needs to advertise whether he needs or requires source. Let me pause there. Or she. Again. Or she. Sorry. It's sorry.  Correlation and causation Doug. I know. Anyway, Think about that for a minute Clemens always keep going to the queue and well your hands up next. You kind of took a step at the point I was made I plus one on the resource model idea because I think eventually what we have to think about is the model of producers sources types events and so on. And whether or not we call that config or make them top level entities in the subscription I don't think it makes a difference I am hesitating on the filters because that could include a nasty language and could make it really difficult to identify the source but if a source is identified and I mean explicitly. I am good with this and I see where Clemens where you're going. But again, where do I have when I have aggregators where sources go on and off even during my subscription. Maybe I don't want to have that mandatory so I don't think this should be mandatory. And another thing why this shouldn't be mandatory is that currently that discovery has no mention of source. I'm not sure if in some people said the service is equivalent to source but I think it presents. Something that can front several sources much like a producer can take over the event generation for a couple of sources and could also be spread in a distributed system where multiple producers produce the same source so with this difficult constellation I think it for somebody discovering a service that provides the events that he or she is interested in. It wouldn't be possible to identify a source to put in the subscription. So currently that link is missing between the two. Yeah, the absence of it in discovery doesn't mean that should be there. When you say absence of discovery, where do you think source show up here. We have source there as a source template or pattern I keep forgetting what its name is. Wait a minute. Hold on. I think I'm in the wrong branch. Yeah. Oh, are you still in the in the bat one. Yeah, we got a PR for that. Don't worry about that. Where's source. Oh, yeah. Okay. There we go. Okay, you're right. Okay, we just, okay. And it's at the same level as data schema. Okay, so it would be. It's in here then that this level. Okay, basically describe this describes a service that is representing a number of sources that you can go and then subscribe from. Go, go, go ahead. But it's not mandatory. So I wouldn't know how. So point being is there should at least be the any source or stuff field wildcard to subscribe to sources. Well, you can also leave it off. I think is what Clemens was saying, right? Yeah, this would be optional. It's definitely optional. Like, so if you, if you have, if you, if this is your only choice, if, if the thing you are interacting with is the thing is actually that's emitting the events then the source is implied it is the source, which means you don't need to go and specify it. So this is really only if the subscription manager is acting on behalf of sources that are not itself, then you would have to go and refer or refer to the sources somehow. I think you're next in the queue. Good. I was wondering exactly also if it should be the service instead, because for discovery said that source might be very fine grain might be hard to even list all sources. So always require either full match or leave it out seems that I don't know, I would also like to have something like wildcards for example. I might have a huge number of sources but I know the naming scheme for example in the path segment of the URI or something. So I could imagine to select a certain amount of sources. Well, so, so if you do this. What is the, what is the way how you unsubscribe thought that this subscription here I get an ID for my subscription. Yeah. Because there's a delete what they don't have it. And in the aggregator case, if you update that subscription, it would get an implementation could possibly cascade deleting certain subscriptions that it created that no longer apply because the subscriptions been updated to be more specific. Okay. So okay Eric I think your hands up next. Yeah, thank you. As I didn't come into this call kind of having made this distinction but I now end up being relevant in a second but I was kind of a little opposed to what you did in config dog because what I was seeing there seems to belong more and filters as far as I'm concerned there would be a very small translation into those as you know whatever the GitHub API uses some for so it would be still very very low effort. The same way that they're going to have to pull up this Jason and do the right thing with it right but one of the things I didn't come into the call with was this notion of both a static and dynamic. And that's the idea of kind of the application of what events and safety. And to be a little more specific about that there, there are. We are trying to describe an API that is going to declare the correct behavior across a whole set of scenarios and a lot of them we won't we won't know their implement we can't know their implementation and. The filters are going to be a comp site. This is the big thing, they're static and dynamic and some of those parts of those filters are going to be static and that's going to have to be weaned out of declaration. And that can be sent for configuration and then another piece is going to have to actually look at the things. So, you know, for example, if everything's running through some kind of an event queue, or you know, Kafka or whatever. You don't know what messages are routed into that event queue, but within that subset you're going to have to only a subset of the events are being requested or filtered to, then you're going to have to sit there and look at everyone to pick up the right ones. And so this is what I mean about kind of the static versus the dynamic is that you're going to have to establish some listener to that queue. It's going to consume those messages, and that there's a active listening and relationship there is the static part of that well the dynamic would be then the filtering over the events coming through that queue. That's right. That's a good piece it seems like it might be useful in this conversation. That's reflects my that reflects my thoughts like there is a, there is a filters are effectively the way how you how you settle out which which of the events that are coming by you really want but then there's this the acquisition of those events. And that's to have some way of scoping. And that's, and that's what I, that's what I was missing.  But it's so let me back up though, actually first Manuel is your hand up is that all there is that new. So that's okay as I thought okay. So, Eric, as you start off the conversation by saying you were uncomfortable at first with what I wrote here but by the end. I'm actually okay with that because of the because of what comes has been pushing pushing us on which is, he needs a way to get that in essence static data to know exactly which thing to turn on the events for. So are you okay with this. Me, I think that both config and filters are going to be pretty specific to whoever whatever subscription if you're speaking to so exactly how each implementer wants to make that choice. So I'm thinking static things, making static things go into config and the dynamic ones go into filters that that seems like a reasonable way for that to happen. I definitely have been thinking a little differently about it previously, but it seems reasonable enough I'm, I'm far more okay with it than I was. Okay, but I had to open my mind a little more to be that way. I actually really like the terminology using their static versus dynamic. Because I think that aligns well with I think the PR we approved last week which is this three step model we have which is, you create the event then you filter the event then you send the event. And if we be a little more explicit about it, and say you know filters are meant strictly for filtering a stream, you already have a list of events flowing through it. And therefore just reducing that down. They're not necessarily for controlling which events get generated per se. I think that might help add some clarity, but at the same time. I think a particular subscription manager could choose could could still choose to say you know what, I'm still going to do everything as a filter, because the way I chose to implement everything to the covers, it is a filter. And so we subscribe to one version of GitHub and may look like this, but another version of GitHub may actually look like this. If they choose to. And I think we need to allow for both. But I think the metadata for the discovery service just needs to be very clear about what they're expecting so for example, the metadata for this, this one may not have any config options at all in this section, whereas the normal GitHub one may it may mention, you know repo owner or may call it source it's up to it. But you should. I think what you're what you're doing here is you are if you talk about if we stick with GitHub, right. You're moving a, you're effectively shifting a lever over the graph that is that is is GitHub. Right. In, in, in, in, if we look at this at this year, right. You are placing the subscription at the root of GitHub. And I'm now filtering everything down to the exact events that you have but everything in GitHub is a candidate. That is, I'll give you an example, I'll give you an example in in a parallel example in broker world. Right. That is how MQTT works in QTT. You have a broker that has a wide open space and you just jam all the events into it and then you create a subscription into subscription can basically pick it from from the root, or it can go and pick into any depth of the topic hierarchy, but, but you only it's it's only access a filter right the topic name the topic prefix actually in MQTT is a pure filter condition versus a topic in MQ, where you are creating a channel for messages that you're sending through that particular channel. And then you can go and create a subscription on that topic, which will then go and allow you to go and filter all the messages are coming into that topic but none of the messages that are going into a different topic. Right. That's the so there's this there's this this wide open space where you have this giant this giant space where all the events exist, and you can go and just filter into them. You have this very explicit split between a topic which means a channel through which which events flow onto which you can then subscribe and then, and then filter filter for the things down which is a concept that doesn't exist in MQTT I think that's that exact split here. Come in in broker terms. But I'm not sure whether you're agreeing or disagreeing with what I was saying. Yes, there is that I think there is a. I think this this can exist in the other one are exist but I think those are the same model. It's just, it's just here in this picture, you are choosing to simply subscribe at the root of whatever scope that subscription manager has. And the other example, you are subscribing to a subset of candidate events, which are then be filtered down. Right. And what I'm suggesting is that we need to technically support both. We don't need to do anything special to make it happen. We just don't need to, we just need to make sure we don't put anything in the spec that would preclude somebody from defining a GitHub type environment that takes a filter expression that looks like this. Yes. I also think that GitHub would not like to do that but but yeah. Yeah, but that's because they chose to implement it because it's very possible for all we know actually GitHub may actually generate an event for every single repo for every single thing and actually do it do everything through filters for all we know. We just don't know but that's it. Yeah. Okay. And okay so for those folks who are joining the call it's actually wait another two minutes before I get into this since we normally till three after anyway. So look at this. Clemens, you were originally talking about sources being some top level thing but what do you think about it being under config since that's it's sort of controlling which thing or how events are being generated. The only reason why I'm a little hesitant for that to be under config is that config was, I thought of config as a very generic bucket of key values that you would hand to a application to the thing. And you would then configure it so this for me was I had in my mind that that's just proprietary per subscription manager data that would then kind of like if you have a timer, you can go and configure the timer like goes to configure those things, but because source is a concept that is first class and cloud events. I was thinking that that that that would be also something that just doesn't sit side by side with all the that config stuff, but with is also first class in in the subscription. And that's the distinction ultimately, I think of this as a more or less as a naming decision decision and as long as there is a well defined place for it. I'm okay either way I just thought of the config bucket as something that is more free form without anything specific being defined in that in it. Yeah, I guess we could we can I guess noodle on the exact location later but I was assuming if it was under here we would say there there's a list of predefined ones that are common. And, and they would look a lot like the cloud events one and so I guess, actually, let's just pause there for a sec because I know we got people joining new. And what we decided to do was to take the top of the hour to go back and exit for a minute, the deep dive discussions and talk about sort of the governance type thing that way people who can only stay for this one hour, the normal hour, we'll miss out on that part of the discussions, then we'll jump back to the normal deep dive discussions. Is that okay everybody. All right, so anything from the community people want to bring up that's not on the agenda. EU, so we have coming up fast, but keep in mind, Remy's volunteer to talk if somebody else would like to talk please let me know. We have until the seventh to let them know. We do have an SDK called technically after this one, we're going to do the exact same thing for that call at the very at the top of the next hour. We'll switch over there we do have one topic as of right now, but when that's done will switch back to the deep dive of the design discussion. Discover interrupt but I don't think there's anything much to mention from last week unless someone else was on the call can think of anything. Okay, now during anything, Tim or anything you want to mention from workflow. I just real quick going through issues right now the only thing that we're going to working on is looping structures for the language so. Okay, any questions for. All right, cool. Thank you. Just a heads up if you're interested in the discussion about the Linux foundation mentorship or the Google summer of code thing that is as of right now I believe the only topic in the SDK call. So if you're interested in that, stay on for the SDK call at the top of the next hour. Okay, now let's quickly see if we can get through these PRs to get back to the other exciting topic, the deep dive. All right. Okay, this was Manuel's been well you want to just quickly refresher but his memory about this one. I have to put my own memory on this. So consume with the other discussion if you want, we can look at this very quickly. Yeah, let's look at the issue I think you have to down oh yeah so spec versions said to be a list of strings but actually the specification was using an object. That needs to be fixed, then subscription dialects. The description, or the type has typo. It's a value is, and this has to be fixed but also in other occasions list is used, and it's not a ui ref list of your references but strings so just say list of string values. To align it with the specification the fields ID epoch and subscription dialect were missing altogether. And the there is one more complicated thing that is the spec currently lists all the parameters and then we have one subtype so to say a sub object. It's called types, and the fields of that object are listed alongside the top level parameters in the specs that this should be separated in the spec Markdown. Also, I would switch the name type to event type to make the schema more clear of what this object is type kind of confusing. So these are the changes. Okay. Not a huge list, but anybody have any questions concerns comments. Okay, any objection to approving. Excellent. All right, cool. Thank you. I think this one might be yours too. Yeah. Okay, yeah, there were parameters in the request body that not sorry not request body for operations. In open API spec that appeared on the path of the HTTP request and those parameters cannot be omitted in any case so there needs to be required to as mandated by the open API spec. So these are the two occasions I can see here. And then also there was the other one. Think the any of I reverted so if that's the only change left. Okay. Any questions or comments on this. Okay, any objection to approving. Cool. All right, this one. I believe. I'm in Clemens both notice that the one on one branch actually had a couple errors in it. First of all, all the specs still had this section that said it's a working draft. So I went through and moved all those. I also removed all of the work in progress specs, meaning the discovery, subscription schema registry, those kind of things. The only other thing, where is it. That's working drafts. Okay. I did decide to keep the protobufs bucket spec in there because that's not as much a work in progress. It's kind of done. But I did change it to say to release candidate and I left it in the 101 branch. I wasn't sure which way people would want to go on that. But I think everything else is what I already said removed the new respects and change and remove the working draft stuff. Does anybody have an opinion on this one think it went chose the wrong direction to go on this. Any objection then to approving and changing the 101 branch. Thank you. All right. This one. Let me just see where we are. Let's ignore this one because I'm still going back and forth with this gentleman and I don't want to merge it in case he actually wants to make more changes so let's let's skip that one. It's not it's not urgent. Okay, slinky. Would you like to talk about your document that you put together. Hello. There we go. So it's the document pretty much similar to the other one. We did the France that it's, it's a sequel like language. So, you know, you choose the one where where is this latest one. This is the, the sea like. This is the sea like. Oh, okay. Hold on. Where's the URL to it's it's in the issue. Hold on. Issue the issue. Here we go. Excellent. Over here next to each other. All right, take it away. Yeah, as I said, it's pretty similar to the other to your solution with a difference that here we are using the, the work clothes syntax of the sequel. And I took some parts from the, from the, the spec that clients proposed. I recognize the wording. It's just so fast. Come on. Yeah, no, I just converted from documents. No, apart the jokes. Well, just check it out. There, there's really nothing more to say that this is similar. It has the, the same goals of the other spec. It's just that you were looking at the different syntax. Yeah, so it's like, this might be an example this one versus this one. I still didn't answer still didn't elaborated out to timestamp works, and we don't have a type for URL, I guess, for your eyes. For your eye, your eye reference and time. I still, I just didn't elaborated that, but I guess we can put it here. So, I don't know. I would love to have some, some feedback on really which direction we want to take. Yeah. All right, any high level questions. We'll give people time to go read this offline, but any other questions for slinky. All right, cool. Thank you. And that's it. Okay, so before we jump back to the design deep dive discussions. Were there any of the topics people wanted to bring up. Okay, in that case, if you're not interested in the SDK stuff, and you're not interested in the deep dive, which shame on you if you're not, you're free to leave other than make sure if you do leave I have you mark down for attendance so let me just quickly run through it. Since I usually do this verbally anyway. So Lance I got you thank you. All right, Lucas are you there. Yes, I'm there. Okay, Jesse. Here. I'm John Mitchell, I got you Doug. Here. All right, teamwork got you Christophe Christophe. Hi. Hello. And Chris Christian. Hey there. Okay, what about Sandeep. I don't think he's knew I lost him. Okay, did I miss anybody else. Oh, Lionel, I apologize. Thank you, Lionel. Okay, anybody else. All right, in that case, let's jump back to the deep dive. Okay, so where we're left off it's not like Clemens you may have been okay with this being under config but let me poke on the other people on the group. Did anybody else have an opinion about that, whether it should be a top level because it's special or whether it's just a predefined one or a well known config option. Scott, did you want to say something you can have me. Maybe not. Okay, Manuel. I think of it. Since there is the basic filter type that allows any of the cloud events properties to be filtered upon. I think source really sort of belongs there or should be a top level feeling because config is really very specific. But that's just a thought because it's a cloud events field. Okay, so you're saying you want it up here. So it's the basic filter type for everything. Okay. All right, Scott, did you want to say something. Yeah, I agree with Clemens around config is this very opaque grab bag of config that is vendor specific or whatever the service you're talking to. And if you want to make a very first class things. We should pop it out to someplace that's not in this generic grab bag thing. Okay. Anybody else want to have an opinion or spacer opinion. Thank you, Ryan. Okay. Okay, any objection then to removing it or not putting it under config and making a top level thing. Done. Cool. Okay, so I then have another question to follow on then is source the, okay, two things. The first one is source the only cloud event property that's special or do we need to take into account any other ones type. Type comes to mind for me to type to be a filter as well. Yeah, I was going to say source to me as well that and then this is this is why I want to bring it up because how far do we take this right how to we have we have in our just just to site prior art. Our subscription gesture for an event grid has the the source effectively and then also the type.  And then you, and then from there, whether you want to have all the block events about JPEGs is something you do then with a filter on the subject suffix. So just keeping with the GitHub example, they allow you to specify a list of events need to be a singleton or an or an array or wall guards, how do we, I will probably make that here. So this is like, if I had the choice again. So I would probably make that an array. Yeah, and I can say, simply we have event streams which is basically an array of events specific event types that you subscribe to so it's aligned there too. Okay. So teamers asking why an array. Can you elaborate team or in terms of why you're asking, given what we talked about how something like GitHub allows you to specify more than one. Yeah, just a question. Because, like, maybe I'm wrong here but what if I want to subscribe to a wild card type. Basically, I want to say, whatever source you have available, I want to subscribe to type this. I think types is, I think type can already constraints what you get out of source. So if you just leave off type you get everything. The way I'd implement that is you specify no type, and then you add a filter with this wild card. Yeah, that's that was my next question is do we allow wall cards in here and I'm assuming the answers based upon what you just said Scott the answers. No, this is meant to be more for static things if you want to do fancy things like wall cards that's when you have to use filters that fair. I see these top level fields as targeting a particular producer. Okay. And for that, for that producer, the config is, you know, the specific to them and then from that event stream you could then specify these filters. Like what you said describe that. So if you leave type off then you're just targeting the source. If you're, if you're specifying source and type your spark is your target specifically the source with that type of event.  Perfect. Right. Okay, so I believe I like these agreements after those struggles. Yeah, I think, I think it was a take a while to understand where we each of us are coming from but I think we're getting there. This is good. Okay, so I think where we landed is, back up. Are there other kind of properties that we want to possibly raise the top level. Well, instead of source there could be service it's not a cloud event attribute but it's known from discovery. Yeah, the question is whether, whether service is the right term there. I think that's true. We've been struggling for service quite a while and had a lot of terms. So something significant enough that the top level is important. So wait, Eric, I'm not sure what are you saying this, we should keep it source or change it to service or what. My question is, what is, we're having kind of this debate over whether something's important enough to put in at the top level. I was wondering what, what's the basis for, you know, kind of at a level up for putting something there I guess. I don't know, I didn't raise an objection but I do think it's a little, we, I don't, I don't know why we would put source at the top level rather than Anybody want to respond to that. Yeah, I think what we were with that was that conflict is a generic property back that you give to the implementation and that input and that might contain application specific information about, about how to configure the, effectively how to configure the source for, for, you know, by what cadence it gives you events or, or some other, some other, some other information. If you want to give the source specifically. That was my original thought about what config would be it would be totally like what, how do, how do I want this rate limited what kind of properties delivery my interest in. And that's why, you know, originally, Doug, putting the config there as you had it seems a little odd to me but I can also see maybe if we use kig config as a space for the static stuff why that maybe makes sense or something but then elevating some of the cloud event attributes into the top level I mean I guess we're guaranteed to have them and but but it doesn't necessarily seem very clear why they're there. I don't know. I think I'm internally justifying it as the, this particular producer can provide you the entire schema of what it expects config to be and we don't have to do some funky two way merge of some properties we define plus your custom config. And here's what the final config schema should be. Sounds like great reasoning. Thank you. So, okay as we write this up is it very, is it fair to say then that these types of properties are for as Scott said for targeting a particular producer, where these are just for configuring the producer. Is everybody agree with that kind of a description, because I think we need to put that into the spec somewhere. Okay. So hold on a minute here. Let's go back to the cloud event spec. Okay, so are there other properties here that should be top level, especially when we start to ask that question. That's when I wonder why source wouldn't end up in the filters. I think we're trying to pair it with the discovery contract, not the cloud events contract. Let's go back. No, this one sorry. Sorry. So, got you mean we're trying to map it with these things. And sources, sources missing. Because I got to be honest with the Eric, I'm actually okay with where we're landing or where I think we're. I'm okay where I think we're going with this but I do agree with you, it makes me very uncomfortable because I hate the idea of because oh we're the spec authors we can say what's special, but users who use the spec can't. Right, our data special, and I always been bothered by that. And, but I also understand why we're landing where we did. Right. I'm expressing it weekly. I, my role here is to be not so dumb end user and kind of service a representative I'm not really on the block for implementing most of this. These are all good points with what everybody thinks. No, no, no keep keep keep bringing the stuff up it's all good. It's only making it better. The next line is it as the these top level fields help you find the entry in the discovery configuration. Maybe that helps filters are crossed out are we saying that filters are not a thing. No, no, this was just in my particular example I crossed it out to say I'm not using filters. Let me uncross that out. It's obviously going to confuse people. There you go. It is there is just optional. Because config comes from the discovery as well right. The schema for config. Yes, it's right here. It's specific for a service isn't it. Correct. Yes. And events defines what what you might filter on, because that shows you the kind of payloads and expected values. And so our next goal is how can we find this particular service entry from the subscription creation. We don't need to care about the subscription config or the events so much. Never thought about that way. I don't know if I like it or not. Well, I guess I'm struggling with, why would you need to find the discovery entry from this. I think the that is how you find out. That's how you know which producer is going to be subscribed upon. Okay, I think I get that. I think that may be leading to what the question I was going to ask next which is, what are the values in here. I mean, are we expecting this value to be the exact value that you would see on the event that flows. And would the user always know that in advance. So to go down this all the way what if that instead of source was discovery service ID, right, there's a service ID there. What if you just use that thing, because it's very specific on who you're talking about I would like to subscribe to that service because that's that's the intent right to find a particular producer, but can't it isn't a source a URI though. It resolves to URI but the, the producer and the source potentially could be different because I'm talking to an aggregator. Yeah, the service is not necessarily the service is not the service identifies the subscription endpoint it doesn't it doesn't identify the sources that are available at that at that point. It's not necessarily. That's why we have a, that's why we have a source template there. Right, right, because not in the example of that. Yeah, here I keep forgetting it's not there. So, okay, so let's go back to here. Is this going to be a URI that has to exactly match the source value that would appear in the cloud event. That was a yes, Clemens. I say yes. It seems over concerning to me. So if it doesn't match what does that mean. Is that confusing to people. If they put a source value here but then the actual event themselves the get is different. And if it's different what does this value mean then how does that, how does the user who puts that value in there know what to put in there. Right. And specify that. What if they also want to specify the subject. And that goes back to the question of which properties do we want to elevate right. Exact mention sources very fine grant. Yes, it's it's the thing. So, I'm always going back to the to the to the principal position of saying the sources the thing that actually that raises the events. Yes, but if you have a certain scheme of defining those source your eyes. So it's a select according to that scheme. Then we're back to then we're back to having a. I mean, we can, we can, we can potentially allow for well cards there. Or some prefix scheme that then catches a bunch of those sources. I will. I will personally allow it but I'm not against having that and not necessarily have to have against that against having that in the spec. It's just, I, I just, I still want to have a clear differentiation between what what sources here, and what what the filter is it's still about the acquisition of the events, and not about filtering the stream down. So those top level attributes are for routing subscriptions up scream and the filters for the opposite direction. That's how I see it. Yeah, exactly. So what what one practical here that might be interesting to think about is, you might have a system or a consumer that is interested in subscribing to a source, but it doesn't it's not aware of what the source is right. And there are cases where you want those things to be to be as decoupled as possible. And the source might be created and and move through its life cycle faster than the consumer can actually discover that it exists in the first place. And so I think there is maybe a case to support the temple eyes and well approach here. So if we allow wildcards in here. We probably then would need a mechanism by which the subscription manager can advertise whether they support wildcards, or are we going to mandate they do. And are we slowly heading down the path of dialects, so you can support fancy. We have the fancy, we have the fancy thing in terms of a source template right. discovery so so we can probably repurpose that idea and also allow that. I would actually have to type this and not put blob store slash star. So they would have to actually know this syntax in advance. It's called bucket. I have not. I have not even though it's my surprise you I don't have RFC 65 70 in my head. Shocking. Well, I'm just looking at this example right I as a user. I'm not sure I would easily be able to discover this or want to be bothered. I just it seems like a lot of work. No, I don't know what I don't know whether whether that RFC probably even supports what allows for wildcards. It might. How about we click that. I was going to say please don't make me open it. Sorry. Well, the word wildcard does not appear in the document. I don't know what that means. It has question marks. It has. I do see stars. It's an explode modifier. Oh God that's a that's a that's fake it's pretty complicated is it not. It's a one level. What is it called? Yeah, the reference altogether. We intentionally restricted us to the first level. Because it's so complex. Yeah. So here's level one. Are there no implementations of this. Just to check it. Okay. Okay, so they don't go ahead. Not the right choice. I'm sure there are there are wildcard. There's a wildcard thing. Open API supports level one and level two. Of this. I just I'm getting very nervous. This is going to end up being basically a filter from a syntax perspective. And maybe we have to go there, but it just it just amuses me, given that we pulled it out of the filter. All right, so we could go back to thinking about that this field as selecting a particular entry in the discovery list. I'm still fascinated and confused by you wanting to link this back to the discovery spec. Yeah, so am I. Because you use discovery to find out what you can subscribe to. Yeah, it's a subscription manager discovery mechanism. Otherwise you need discovery in the subscription API. Like you need some way to know what this is going to do. And so that the two specs are. They, they leverage each other. Yeah, yeah. But discover is also optional. So it's understanding what you're going to do. No, what I mean is, I'm, I, if you're suggesting that we should replace source with just subscription ID, I'm not sorry, discovery ID. Service ID. That would mean that in order to do this kind of matching of the source or the producer, you'd have to have a discovery spec implementation there as well. I mean, I could be off base too, right? It's not unheard of. Okay, hold on, man. Your hands up, man. Well, is that older? Is that new? That's totally new. I want to say on the source that initially with the whole discussion I saw specifying a source and that is an exact one meant that it allows the subscription manager to make a subsequent or transient subscription to whatever the source is. I also had a feeling that this might, being a top level element that this might render the subscription valid or invalid. So when I specify in an exact source that does is not known to subscription manager, then it wouldn't allow this if it really is is now the way this has been talked about. I totally agree with you. It's a filter now and this is completely super fluent to specify it as a top level element. That's my opinion. So I think what you're suggesting is it's a static string, no wall cards. I think that was the background when we talked about it earlier, wasn't it? Yeah. So from my implementation preference is that's it that is indicating the exact source. And it would be the exact same value you would see in the cloud event. Yes, that's my that's my implementation preference. I'm not getting in the way of, of, of wild cards. But my implementation preference would be for that to be the exact URI. Well, one option is to go with something as simple as that. And then as we start implementing this and playing with it, we come back and revisit it later. That is one option. What do people think about that? You could try that. I think as long as it's possible in filters and the support of the various dialects for filters are optional. I think that gives enough flexibility to the implementations to choose what they want to support. And just, just from a, just going back, going back into, into implementation detail for a second. I can, I can obviously make a subscription manager that can offer subscriptions at all kinds of levels, which means I'm again sticking to the storage, the storage account example. So let's say the source, you come to me and say that I want the source for this to be, you know, HDP storage service slash container. And then, and then everything that happens is have that a container that shows up to you as as events where the source is being set to that container. The other object is then the path, the remaining path, the relative path of the file that was just created of change or whatever. And then I can have the same subscription manager you can walk up to it and says, no, my source is actually service slash container slash directory slash another directory. I only get events for that scope with that your eye being the source because that's the thing I subscribed on, and then the subject being the relative path from that your eye to the file that was created. And then I can create this, I can create this flexibly it's not that that I'm necessarily constrained by the subscription manager can can go and interpret and create scoping where, you know, splitting up the, the, the, the, the identifier for the thing that the event is ultimately about between the subscription scope and then the, the remaining scope that is then expressed in the subject. And then I can just make the flexible. So, so making this a concrete your eyes that necessarily limited you in, in, in how block the scope can be that you can go and subscribe on. Anybody want to comment on that. Okay, for some reason I will, the raise hand feature is gone for my reason of zoom, so I apologize. But I guess. Partly to, to come as point, but, but I guess a step back is what I mean, you know, given that we're working on the discoveries back and this and workflow and all these things like what is the, you know, what, what interoperability is is required versus optional versus something in between. Right. Like, how many different models are we trying to shoehorn, what are we trying to make the sort of happy path and try and get people to, to, to go to versus what's possible. Which I, which I think, I think, I think we have to have some kind of position or bias or something and what, what is the expected flow of how people are going to use things. Because otherwise, like, it's too open ended, like, too many people do too many different things. I agree with you, I think, I think, and that's part of I think why this discussion has been so good because I think we're trying to find that balance between flexibility versus being, you know, too prescriptive kind of thing. And that's why I think based upon, but let's say we stick with what we just have here, right. I probably would now rewrite this example. I probably would not put these down here anymore. I would actually all three of them. I would, these would all in my mind be up here someplace. I think that's getting closer to what I think you were looking for, John, which is a little bit more of a commonality to get interrupt. Yes. So this is all good. Okay, so I think we're talking about is forcing this to be a singleton, you are I must match the CE source is going to appear in the event. Is this all cards. Are we okay with that as our current starting position, and we can revisit later as necessary. Hold, hold off on the cheering until I get a company. I was going to check. Anybody wanted to voice an opinion against that as a starting point. Fine starting point. It seems likely that that's going to be problematic for some use cases. Okay, I would start there. Eric in particular since you since you believe that if you can think of one that isn't completely insane. Can you open up an issue because I would love to use that as a forcing function to have more discussion about this. So if you if you think of one. Um, cool. Thank you. Now type. I'm assuming I don't know what type is whether it's just a string or you arrive or whatever it is in the CE spec it's going to this is going to be a ray of those things. All right, everybody. Okay. And in both cases. Okay, well actually maybe not. I was going to say that in both cases these are optional for the subscription manager to support but now I'm not so sure. Obviously it's always optional for the subscriber to include them in their subscription request, but should these be optional for a event producer or a subscription manager to support. I'm still leading towards making them optional for the subscription manager but I'm not 100% sure to be honest. Clemens were you saying you agree with that. Yeah, I think those fields are optional because there's an there's an implied value if you leave them off. Well, the way you just said that implies they're optional for the subscription to include. That's not the same thing as the subscription manager. That's not something is it being optional for the subscription manager to support. That's true that the subscription manager always knows the source. It's just that whether it's told by this by through the message or whether it knows it intrinsically that's the quite that's the difference. Okay, so you're opting for type and source to be mandatory for the manager to support. To know yet type source yes type no. Okay. What other people think about that optional for. Client required for manager. And this is optional for Kai. Their manager would have been thinking about that. Yes, no. This is Jesse I guess I would be concerned about the coupling aspects of that if it's required to know the source of things. What impact does it have on. On coupling. Can you elaborate a little on the what you, what you mean by coupling me for example in the aggregator case that we keep talking about is that mean the aggregator has to understand all sources in advance. Exactly. Yeah, I mean, there's situations where you're just where you don't have to understand the where the event is coming from you want to be the sort of indifferent middleman and just distribute messages from whatever source comes in to whatever destination based on say a topic string or something like that which would typically be the type in this in this use case, the source is irrelevant unless you choose to make it part of the part of the type. You know, if you have a naming structure that would allow it to be part of that type. So I would say for some managers that that source is irrelevant. I'm actually going to push back on the wording I think Clemens use which is that the manager has to know about the sources and I was going to think of it differently. Well, yes, they may in some implementations, but in the aggregator case it's more, it's more. The aggregator must be able to must be would be forced to accept this field, but how they choose to implement it is up to them, meaning they could end up merging it with the filters and turn it into a filter right. I guess if you if you are cloud event compliant, and you have to accept the source element. Then that makes sense that you know, your filter would be able to be filtered on the on the source that makes sense to me. I was I was going to say I think there's a difference between like having semantic knowledge around the source and knowing what the source string is because if it's quite a bit compliant like that those are, those are in the cloud event right so they already have access to that so why would that be, you know, more complex to require supporting. So thinking through it just sort of our implemented implementation solace, you know, our sort of baseline implementation wouldn't have source we don't really care about the source it's all about, you know, the topic string. But if you know, we are presumably cloud event compliant, then we could potentially implement the sources of selector and then you know that's our and the underlying implementation of that would be selector based essentially. So I guess, yeah, thinking through it more I guess that makes sense. Okay, so we're saying it's okay that it's required for them. That doesn't mean they have to know in advance they may end up using it as a or doing. Maybe they may end up implementing it as a filter but that's a behind the scenes thing for them to do. That's all right. Yeah. Anybody want to comment more on that one disagree. Okay, just to reiterate we're on filters. I assume that they're optional for this for the for this client meaning whether it appears in the subscription request, but it's also optional for a manager to support. What do people think about that last part. No objection. Okay, I just see did you want to say something. Okay, and just be clear. The minute something like this appears, or the minute we make this decision to me that implies we have to add something to the discovery spec so that the subscriber knows what they can specify filter or not so that implies change in the discovery spec. Just to let you guys know where my heads at. That means a bigger PR or two mobile PRs. Okay. All right, I don't remember for sure if we finished our discussion about other other properties here that we wanted to raise up. I think was subject one of one someone mentioned, or subject too much of a wildcard thing that it makes no sense to ask the person to think of a static value. I mean what if you want to just subscribe to one file in a bucket I think is maybe one of the use cases right Clemens. Maybe to do it as a top level thing or we're going to say no that's a filter thing. Say it again. I'm wondering whether subject should be raised to a top level thing in the subscription the same way we did with source and type. No. Can you elaborate on why you don't think so subscription is subscription is not the subject is not the thing you subscribe on the subject is a description of the sub structure inside of the thing that you subscribe on. So the subject only shows up in the event itself, because it, it further qualifies what that event is is about within that source. So if you want to go and if you want to constrain the subject, then you would go and use that you was if you would use a filter for this. That's in my in my very confident world of, of prior art. Like that. Anybody want to comment on that want to disagree. It's an optional field and cloud event. So I don't see the top level field. Oh, that's a good point required versus optional. You're right. That could be a good point to. So let's just double check sub type. Okay, those both required good. So I double check. Okay. Anybody disagree with that conclusion that no other. No other properties here should be raised up. Okay. Oh, go ahead. I'm still, I'm still going back and forth on whether I think type should be required to support for the manager. Because I, again, the manager already has the type. And especially when it's required field and cloud events, why, why wouldn't we just make that required for the manager if it already has access to that. And we want to comment on that. Clements I think you were saying that should be optional for a manager to support. Did you have a strong opinion one way or the other. I think it's, I think it's optional. Why? Because if you don't specify, I think of that as a further constraint. No, no, no, we're not talking about optional for this, not optional for the subscriber. We're talking optional for the manager. Oh, optional for the manager to know. Not to support. To support to support. I think since we, I think that's optional. And that is because the subscription managers acting on someone else's behalf, and they may be getting events that they don't know about. Okay, I don't think I'm phrasing the question right the way you answered that. What we're talking about is whether all subscription managers have to support the idea of type appearing as a top level thing. Well, that means that I have to act on it. Yes. And acting on it could mean adding it to the filter. If you support filters. It doesn't necessarily mean using it as a, using it as part of your mechanism to go talk to some entity to say turn on your events. I'm fine if we require it. Anybody else want to chime in. Like, like the other decisions we could start with the more restrictive one and loosen it up later as we have use cases as we have use cases. But anybody want to speak up now. All right. Thank you, Ryan. Anything else about these things. Yeah, right. My understanding and the, sorry, the filters have just become optional for the manager to support in my view of the world. So I, I'm not sure if the top level elements that are mandatory and required by the manager to support are now enough for my understanding but that. Okay. Can you say that again with different words? I'm not sure I followed. I was under the impression that any subscription that I can issue to subscription manager can always be filtered by any cloud event field with the basic dialect that is mandatory to support but with the entire filters to be optional for a manager to support that has just gone. So now there is only selecting a single source or none. And luckily, okay, we have the list of types. That's for the minimal portability between subscription managers. I think over that.  If that means data bursts with the either selecting the source or then going all the way and not selecting a source but getting the full blast from that subscription manager. I'm not sure if that's sufficient. But okay, we'll turn out with a little bit of practice probably. I'm struggling. I'm trying to understand what you're, what you're concerned with because I don't want to leave this if this is a problem. I had a previous example of 900 sources and then whether or not we want to be able to somehow limit that. Now the only option I have is having a subscription for each of the 300 that I'm interested in or taking the full blast of the 900 sources and filtering it out myself because filters are optional for a manager to support. Correct. But see, yes, and I think I understand why you as a subscriber can look at that and say oh my gosh that's a pain in the butt. But if that's what the subs if that's the only thing the subscription manager can support, then you're stuck with it. Yeah. Right, because to me the question about whether it's optional for the manager or not is is what is the burden we're going to put on subscription managers. In essence, filtering, I know that's going to be the wrong word to use but filtering on source and type, because they're required properties. And these are just static string as of right now anyway seems like a very, very low bar. It's not a huge ask of them. This requires expression processing. Right, even the simple one that we have that still requires a fair amount of processing. And that may be a two bar of a thing to ask for example, I can't ask that to get up today, as far as I know, this I can, or I can at least encode that into an adapter. Yeah, I mean that's the way I'm trying to understand and it's it's the burden of the subscription manager implementation because that has only self spawned interfaces to all the different messaging technologies underneath so yeah, making filters possible could be difficult for them. Okay, yeah. Okay, and good for now. Okay, yeah, obviously like like everything we can always revisit it later. Okay, any other comments questions concerns about these three. Okay, I mean when we're talking about making, I'm sorry, I'm talking a lot today but when we're talking about making these filters kind of mandatory. It's really implying a certain mental model of the consumers for the people using things to implement systems and, and I'm not sure that I mean like Clemens was presenting a mental model that really has sources something that's really important but but I can imagine a mental model that says the subscription API that I'm talking to it's that that systems job to make sure that only trusted entities come in here, and I want anyone, any source to tell me about things of a certain type or with a certain subject or you know whatever the criteria my model is relevant in my application might be and I'm a little uncomfortable. Again, I'm not implementing these in implementing these things so I'm happy to let the group decide what's best for it but it seems like potentially there's a constraint and a decision about what that mental model application developers approaching the subscription API through I'm not sure that's an appropriate thing to constrain given the kind of broad level of engagement that this is supposed to be specified. Can you be a little more. Okay, first of all, stop apologizing. I love all your input your questions this is all good. That's why we, that's why doing these long design discussions so so keep speaking up. So it's a little more concreteness to what your concern is like maybe with an example just so it's a little more clear my head in terms of what you're worried about like, we're asking the subscription manager to implant X and that's going to be a problem for them. Well, it may just be wasted. So, if in the scope of a particular subscription provider, then the source may be totally irrelevant to that the implementer of the subscription API but also to the client so in this case it's a kind of meaningless thing and maybe that's just an API that's non compliant, and nobody cares, because no one involved cares. But, but in a particular model we really don't care about what the source of this information is. Maybe, I don't know maybe it's something like you're, you're implementing a stock trading system that listens to the events, describing the articles that are being published by all the news outlets and, and you don't really care what the source of the information is but you want anything about any of the stocks that you're interested in or, or perhaps, you know, you don't care, you know, about that kind of filtering and you're going to do some aggregation in your system to identify where you might want to make position changes and, and so by making something mandatory it's kind of implying that that is inherently a part of the model that you're coming with for your application. Yeah, I don't know that that necessarily means we shouldn't make any assertions about that model, but there it is. Yeah. So, so we have a source is something that's material in the cloud event per se. So that that's a required field, which means, I don't mind being told where it came from. I have to then treat that sources of an important part of the specification of what I'm interested in hearing about.  That's why I go to say a news website, because they're listening to all the sources that might have a relevant information about something and they are then writing up interesting articles that inform me about the world right. I want to hear about the source I want there to be one. Sorry, go ahead. Your source is, let's say the New York Times, and it can be as broad as the New York Times but you still have a source. So, so if you if you were so if we're sticking with that example or let's say it's Bloomberg, right. And then Bloomberg has a subscription mechanism and we have those things with ours S feeds, where you can go and subscribe to any kinds and kind of news but the scope at which you'd subscribe is not the, the, you know, the rainbow news or the business news or the sports news but you really want to have all of it. Well then you subscribe to all of it, to all of it you subscribed to kind of the main feed of it, and then you get everything but you still have a source that is the newspaper. You just not scooping it down in any particular way. Sure. Okay, I mean I agree with that. I guess, maybe, maybe the solution then is there's a default value of whatever the subscription API is, you're subscribing to. And that was the, and that was the implied. So, so that's, I said, what I said a while ago was, I think the resource that the subscription manager has an implied notion of what the source of what the source is. If you take the source off here in the subscription gesture, then it's automatically that source notion that the, that the subscription manager has but there's always there, I think there's always a notion of a source. And that's something that's intrinsic to the subscription manager, because that's the UI, it's going to stamp on the messages that are that are being published. I just realized what the time is so I'd like to actually continue this discussion briefly in a minute but it is the top of the hour, and there are I think two things to be nice to happen. One is, if you're not interested in the SDK or in particular you're not interested in the summer of code or the mentorship thing. But you're interested in discussion. Now is your time for a quick bio break. Because I think it's important that we go back and do what I said which is jump over the SDK talk and see if and get that out of the way for people are interested in that. And that's okay with everybody. And so slinky you can't escape. Because I know you that you're interested in this so why don't we assume that we're going to spend five minutes or so talking about this, and then we'll sort of we'll come back and continue the deep dive discussion is that okay everybody. Yeah, and I'm going to step away for a moment. Okay, so looking at 12 after at the worst, hopefully, unless this conversation goes on for a long time but I don't think it will. So slinky. So, I love to be honest. So, so summer code or links foundation mentorship that doesn't matter. So if we want to go with links foundation mentorship, it's fine. The thing is that to be honest, I, I'm not sure we really have some good project for that. We need somebody that takes care of mentoring and I'm not sure I'll be able to to stay to have time for this honestly. Okay, yeah that that's a very big point we need ideas and we need people who have the time to mentor. Yeah, I know I initially said that I, that I want to do that and, and I really wish to do that but to be honest, I, I don't want to be the kind of mentor that doesn't. That's fair. Okay. Is there anybody else in the call who has a good idea and has time to devote to this to be a mentor. So just to do a quick recap for the ideas. My initial thoughts were one is a new a new SDK in a language that we don't have. The other one was pick up the integration test conformance test idea that we had that we tried to bootstrap at some point, but then we never had time to work on it. So to extend the conformance, send the conformance test to test suite and to actually use it in every SDK as far as I know noise decay except colon is using the conformance testing that we developed that we would stop so of the two projects. I don't know, none of them sounds really strong enough. I mean, okay. Hey, Lance a JavaScript is using it. There you go cool Lance. Okay. Anybody want to speak up or volunteer I should say, otherwise we will let the idea just sort of weather on the vine. Well, by the way, the January 31 is for spring, like they do every season, as far as I understood. So the deadline of January 31 is only for the spring mentorship. Like the one for the summer is pushed on April or and March. So I don't recall but it's far. So, if you want to discuss this again the future and we have people that want to want to chime in and propose themselves. Okay. All right, anybody want to volunteer. All right, not hearing any I believe the decision is I mean, are you guys just doing the cloud events as the case if we could include like the workflows the case I could definitely, you know, help out on both sides, maybe. Yeah, I mean this is, I think technically it's anything under the serverless working group so yeah if you want if you have an idea and have the time to mentor for a workflow thing. Go for it. Okay. You technically, I mean, I don't know what the process here in terms of work group approval but I can't imagine you'd come up with anything that's really bad in terms of what that we'd hate the idea. So, if you can think of one, I would go ahead and just sign up. Just keep in mind the deadline is January 31. Okay, thank you. Just. If you do end up doing it just let us know at the normal working group call so the other people want to be involved in some way they can join you. Okay, anything else. All right, cool. Thank you all. And that case any other topics for SDK. I had like a general SDK question. And I know on your website you have this integration sections, you know, the all those companies and all the places, you know, that that are supporting or using the specification. We had a recent request of like putting somebody on there that's using our SDKs and I see for cloud events you guys are not like doing that at all, or at least promoting use usage or other people they're using it. What should I do in that case. I personally in SDK Java in the week me at the end there is who's using it. I just put it. Oh, I didn't see that I'm sorry then. Okay. But I don't do this in other case. Yeah, maybe I should do that in SDK. Be a good thing to do if we have the information. Yeah. Okay. Anything else. All right, cool. Thank you all in that case if you're not interested in the deep dive and you're here just for SDK, you're now free to leave. I'll drop people by it. Okay. So just to try to wrap up the discussion you're having there Eric, before we got sidetracked for a sec. I had to I got a little, little lost when you were talking about your concern because I wasn't 100% clear to me when you're talking about what you may want to sort of get events for whether you're talking as a subscription manager or as a subscriber. And I'm looking at this strictly as a subscription manager at this point in time, because I think you were focusing on this part, right, whether it's required for the manager to support. And are you suggesting that there are cases where a subscription manager can't do any kind of filtering on the events that it may receive if it's an aggregator or something like that. Or yes, saying maybe to bring up a burden to ask of them. I think what I was saying, because I think that's a good. I was probably losing track of that distinction because I'm largely looking at things from a client perspective, but there's I seem to me that there is part of the use case that made it not valuable for the manager to hand have explicit handling of source that source be required, supported. And so, you know, they could implement support to be spec compliant, but not that doesn't make it useful. And so what in the sense that is is saying, you know, if you're not using this, if this isn't important to how in your case events are filtered, you're doing it wrong. And I'm not, I don't think that the group would want to say that, but I But maybe I'm not thinking deeply enough about this so So that's that's why I was bringing up kind of the mental models people are approaching their implementation with is because that then the way that the managers are constrained leads to pretty strong opinion about the API issues. I have one thought here, which is I actually think it's okay. And in some ways important to have opinions about the mental model and how things are structured and I think that's one of the reasons that source and type are actually required in the event spec, right, because you know, from my personal experience, those are always just those are just fundamental things that are always interesting in in the context of consuming events and understanding where events are coming from and what they are. So, I appreciate the, you know, making sure that we're focused on the use cases. But but you know, there's a balance of like going completely generic right and being completely agnostic of the use cases versus having opinions and people understanding what it should be used for. And you know from my experience source and type are you know part and parcel of of consuming events in general. I apologize Eric, I didn't eat breakfast, I didn't eat lunch and it's coming up on one after one o'clock so maybe even just losing my mind. But I'm still struggling. Oh, okay. I'm still struggling with with with what your concern is, meaning. I'm still worried that if we make this required for a manager that it's too big of a burden for them to support too big isn't the concern. It may be useless. Okay, elaborate on that because I'm not because I understand that we see useless is that because they only maybe have a single source that's flowing through their system. Or their entire ecosystem the people that would be interested in subscribing don't care and would never use it. I think just that I think that the point made before that sometimes opinions are important to have completely agreed. And this may be a case where I'm going for the generic too easily. That is a failure mode for me. Well, there's a there's a generic time sort of the generic source of events, arguably, that has zero scoping and that's the wall clock. And still, if you're subscribed into a particular wall clock. Let's say the UTC clock. You will probably still get a source get it get it get a source to just disambiguate that wall clock from any other part of the system. So, I think the, I think there is some, there's always some level of scoping in your events. The scoping is expressed in the events per se, through the source. And then it's optional for the subscription manager to be told the source and that's why we made the field optional. But I think the subscription manager always has to deal with, with source information. I don't think that exists. I don't think the zeros. So there's, there's, there are use cases outside maybe the UTC wall clock that are there that can do completely without scoping. So John your hands up. Yeah, so I was going to ask for an example from Eric but the, the, the, what Cummins is saying let me let me give you an example from the enterprise world enterprise developers are lazy bastards. And so the notion of, I just want a fire hose aggregator that some other team controls.  Right. And then I'm going to pick apart just whatever out of that fire hose that it gives me where I have some other, you know, whether it's a config value or some other filter that is all I care about and I communicate that in whatever custom way it is is going to be how people developers like that actually use the system, because that's actually how they use a lot of these systems today in whatever custom configs that exist. But from our standpoint, that's, that's a degenerate case that like making, making source in this particular thread optional. Like, that doesn't help at all. Right. If people are going to willfully use or, you know, degenerate their use cases where there's nothing we can do to mandate against that. Anyway, and letting, you know, letting providers producers off the hook, or the aggregator off the hook to not support source. That doesn't seem to buy anything in that particular case. That makes sense. Let me rephrase or let me echo back what I think I'm hearing you say. So let's say someone comes up with a use case that says hey I have an aggregator, it's going to get events from a whole bunch of different event producers. This aggregator wants to do is be a funnel for it. So anybody can subscribe to that aggregator, and they're just going to get all events. The aggregator is going to be really, really dumb. It's not going to do any filtering. It's not going to do anything except get an event and then spit it back out. Okay, it's a proxy more than anything else. I think what I hear Eric saying is, that's a valid use case, and therefore it's also, it would be invalid to force that aggregator to do any kind of filtering, including on source. But then I think john you're saying is, Nope, it's not too much. Yeah, so in that case, what what do people do today. They basically, they basically just put a dummy value where the source is the aggregator. Right as a new, I guess, Collins you would call it a scope that that it's just its own scope. And so the fact that it's a complete mass and has you know everything in the kitchen sink in it.  However, you know, whatever magical thinking they use. The problem I think with that is this right here. Right, because if the subscriber puts a value in source, they're going to expect all events to match that value for the source. Right, and that's what I'm saying it's a degenerate case. So we're going to, if we're, if we're right and like a bunch of enterprise developers like I can totally picture hundreds of them. But that's exactly how they think they don't care. They're not going to put it in unless they're forced to. Right, so it's a it's a willful choice and it's a degenerate choice, but it's a choice that people in practice actually make regularly. Right, but so, so they do that, like, okay, that's their problem. But why that particular degenerate use case, in my opinion, shouldn't shouldn't affect us as having a preference a bias a an opinion that that's actually not a good practice. But then our. So wait, are you advocating for this being optional. No, but if it's required, then okay, okay, maybe I'm, maybe I'm so what that's what I'm, that's what I'm saying is, like, if the, if the argument, and I'm putting words in your mouth, Eric, I know that you're actually saying this. The argument, right, if the counter use case is well people do bad things and, and, you know, degenerate things.  Like if we go if we if we try and prohibit willful disregard. We shouldn't work because people will just work around it. Right. So, like, let's, like, let's, we should buy us, or our opinionated position should be, well, here's the right thing to do, and the right thing to do is what what you have written. Right, it should match the actual cloud event source. Right. And if people choose to ignore it, then they're off the reservation anyway. I guess I'm I guess I'm confused though. I think you're implying that this use case is a bad use case. The degenerate use case I'm saying is absolutely a bad practice. I'm just saying, like, we have to be like we, if we're going to take an opinionated stand, people are going to do bad broken silly things, no matter what we require. It's a bad to being overly generic to bad practice is not where we should not what we should promote. Right. So I'm saying it should be required. And if people hack their way around it. Well, they're on their own anyway. Can you elaborate on why you think it's a why that proxy use case is a bad use case. What happens, right, when you have these big aggregators, right. So think about so again, my, my, my, my personal experience is big enterprise. Right, so big enterprise developer has some mandate comes down that says, Oh, we have to interrupt with these other people. Everything goes through this generic proxy. And it's a huge fire hose. And instead of actually reading the documentation, figuring out these filter things because they're too complicated or whatever, they just say, I'm going to subscribe to everything.  And since I'm just a developer and I'm not in ops, like, I don't care about the performance. Right. So it's, it's, it's all it ends up being ad hoc.  Right. That's that that's the, the shortest, laziest path to success so that they can claim victory and move on to the next, their next ticket. Okay, I apologize for believing this point, but maybe I'm thinking about this completely wrong, because I wasn't thinking of this use case as degenerate bad or anything like that. Rather, it's a valid use case in the sense that this aggregator wants all these events from all these event producers, and they want to allow people to subscribe to get the flood. And what they do with it down the line is up to them. And in that particular model. I, it seemed odd to me to say, Hey, if I want to, if I want to write a proxy subscription manager who is just doing nothing but sucking in events and then spitting them back out. I was wondering whether it's too big or burden to say, Yeah, that's great. You want to do that. But you know what, we're going to force you to do filtering. I don't, I don't have a valid use case other than it just seems like a natural thing that someone may say, Hey, I want to write a proxy subscription manager. And we're going to say, Nope, sorry, you can't do that. You have to support filtering at least on source. And well, not type. Right. And that's fine, because they can make the source be that proxy. True that can that's the source and they're going to dump everything through that. But they but then it's not a proxy right because if they change the source value as it goes through the proxy, then they're no longer proxy. Well, so that that now we're now we're getting to ownership and who's who. Right. Like I can tell you in in the, in the, in the, the big enterprise that I have recent scars with, like, that's literally how people thought. They didn't, they, they, they explicitly didn't want to like, they took this fire hose example where they just saying, Hey, we're a, you know, we're some kind of operational or security system and we just want to see all the events that we're going to do. You know, some kind of analysis on it. Like, they're not going to, they're not going to filter on that anyway. They're not, they're just going to say, Hey, whatever comes in, we're going to ignore things like those source fields, except for in our actual analysis. Right. So they're doing their own downstream filtering or whatever you want to call it. Like, and that's totally fine. Right. But that's what I'm saying going back to, if we, if we're going to take an opinionated stance, we want to make the bias and the mental model, right, which I love thinking of. We want to, we want to bias that to what good practice is, as opposed to the, the, the edge case. I need to think more about this. I know Eric, I was way off where you're headed with this, but anyway, it was an interesting discussion. I definitely didn't mean the degenerate case. I think there are some valid use cases, but I, I, I worry about throwing the baby out with the bathwater. If we disallow the degenerate, I do have to drop though. Okay, thank you for the discussions. Thanks Eric for the discussion. Good ideas. Yeah. So come in. Yeah, so, so I feel that same pain. And I completely can follow it and then also have the including the enterprise developers are, what did you say, lazy bastards. I'm not make that as a generic statement about all my customers but I've seen some of those. And that constraint is one where I would say that's an implementation policy decision that we should enable and make possible and any same implementation will probably put put some some lid on that. And that is where you really want to have the ability to go in and and and pull through a fire hose for purposes of replication. It's not an invalid one. So if I, if I have this, if I'm using the subscription mechanism to say, I want to have a replica of this event store somewhere else. And the way and by creating a subscription that's how I established that that relationship. Then I actually don't care about the sources and the types at all, but I simply just want to go and set up a relationship between two parts. So there the subscription manager is the scope of that is, you know, implicitly everything that's that's that's in that store. It might not even care about the source in particular. Right. Sorry to jump in, but in those kind of cases for the legitimate case where I was trying to support Eric in the degenerate side, but on the for the for the valid side. I mean, if we're going to say that then to me what that what that says is what what is a valid thing to put in the source that actually makes explicit this view of no, no, I literally want the fire hose on purpose for exactly the like your like you're saying the replication use case, for example. So I think that value in that case would be leave source off as a subscriber. Yes. Right. And I'm sorry, go ahead and close. And then it's really up to the subscription manager which what what what the subscription manager gives you, like you're no longer being specific in the subscription. And then you are effectively in a world where you have a private relationship between the subscriber and the subscription manager to kind of sort out what what how the relationship of that subscription to the sources is. So, so, so hold on on the because now we're talking about that's that goes under optional for client. Right. But that. Yes, I worry, like I one of my one of my checks is always being explicit versus implicit behavior. If we're saying this is a non trivial or use case, right, that people explicitly want to be able to do. It seems, it seems like a better thing to actually make that explicit, as opposed to a degenerate, you know, the empty string has has a meaning. And it's implementation defined versus saying, I want the fire hose explicitly that that that communicates intent, right, and changes the view of when I'm looking at this subscription. So, so, John, I think that's that's that's almost a separate discussion, though, in the sense that I think that's more of a syntactical discussion. Right. Are we going to, are we going to allow source to be missing versus empty string and what does though each of those values mean. That's a discussion but I think it's separate. There is a So that might be there might might have a construct. That is the anonymous source. And there's a there again draw drawing was a prior arts, there is a construct and in compete called the anonymous terminus where you're explicitly saying, this is a junior. So this is a generic shoot a generic channel that where I am explicitly saying, I actually don't care. I give up all my opinions about the content. There's a dressing model that's inside of it. And I'm just allowing you to have a place in my broker in the case of a p where you can go and send stuff to and I'm changing the, the, I'm making exceptions for for how we're going to do addressing. And that's not an anonymous case because it's really for the proxy case and that's really for, if you're building in peer routers for instance, that's where the anonymous term is this kind of kind of comes into play and I can see that we explicitly say there isn't a concept of an anonymous source, which means there is a special case your eye of sorts, or some some some expression, which says, I am subscribing and explicitly say that I'm really making a proxy firehose subscription year for everything that the subscription manager has in scope. So, I still want to go back to I think that's a separate discussion. It's syntactical around the source, yes. Yeah, so but I don't think that's what Eric is focusing on. Okay, so john I agree with you that we should have a discussion about how does someone indicate. I don't want everything, right, whether it's absence of source or source with an asterisk or source with a world of fun URL, we can have that discussion, but I don't think that's what Eric was focused on. Okay, so let's assume for a minute, you have a scenario where there is this aggregator firehose proxy thingy. Okay, and someone can subscribe to it with whatever syntax that says I want it all. If we agree that that is a valid use case. Then, if this subscription manager says they are compliant with our specification. It is then valid for someone to come along as a subscriber to say that's great but you know what I don't want it all. I want to subscribe to that, that manager, but I'm going to put a source in my subscription request, and I'm going to say get up or something like that. Okay, we've now placed a burden on this proxy to filter events coming through its system to to just get up calm. Even though he even though he went when that code is written, it may have been written with the assumption it's only going to do firehose and everything. You know, everything's going to go through it and everything's going to go to every subscriber. So I've placed a burden on them to support filtering in some fashion. And I think that's what Eric is concerned about. And I'm trying to forget whether that's a valid concern, or we want to say, No, tough, you have to at least support some level filtering.  If we choose to make this optional, then yes, the discovery spec needs to have a flag in there that says for this subscriber that you're going to subscribe to they either support or they don't. And if they if they say they don't support it, and someone subscribes and they do specify a source yes I expect to get an error back saying sorry, you asked for something I can't do. And keep in mind, I'm not saying whether this should be optional required. I'm just trying to play stills advocate with Eric's position. Okay. No, no, no, that's that's this kind of goes back to what what I what I started off a lot earlier is trying to figure out what what what what what is the bar what is the, what is the requirement versus what are we, you know, how, how, how interoperable are we trying to be. Right. And I think, I think there's two different levels of interoperability. Okay, there's interoperability from a more of a syntactical perspective right do people understand. And we have consistency on what it means for these values to appear in there and how they're going to be used and how people should use them and stuff like that I think, I think we all on the same page there. Okay. Then there's the different level than the other level of interoperability which is, does everybody support what they need to support. So they actually becomes useful and this goes back to I think what Clemens I've talked about in the past is, you know, in the WS star space. You know, interoperability, but from a spec perspective, but we had zero interoperability in reality when it comes to security specs because everybody implemented their own specification and this and they're in the WS security specs said, you know, you can use the dialect you want, in essence, and, and, and everybody chose their own. So yet zero in our building in real world. Exactly that worry. Yes, I have the same scars. So I totally agree on that being a problem. Right. And I think that's what I that's right. So, that's what I think we need to focus on here is to say okay if we change this from required to optional. Have we now reinvented that pain point that WS security had. I implemented everything wrong. Yes, exactly. I'm crying on the inside. Yeah. Right. So, I don't know the answer. But to be honest with you, my gut reaction is that making this optional is not reintroducing that problem. Because I actually do think for some people it may be a tube high of a bar to say hey you need to at least be able to filter on type and source. Yeah. But I don't have a strong enough opinion or enough background to know for sure it's just my gut feel is that those both should be optional. But I was willing to start out with them being required to revisit it. But since Eric forced the discussion. Here we are. So I might get says they need to be required. But like with content negotiation. If, if I don't support that as one of these aggregators, then when you make the subscription attempt, I should respond with an error saying, you know, sorry, I don't support that. I think that it's explicit the whole way through and there's an actual, you know, error response or whatever to make that clear, rather than having it just. Well, you know, I'm going to send this subscription hope it works. Have a nice day. Well, no, I agree with you if we if we choose to make both these optional. Yes, we have to have a very clear content negotiation as you call it. Yes, totally agree. No, well, in that sense I'm saying, if we make it required and explicit. Right, we can cover those cases and great. So it's required. And the, but the, the, the, the, the, the interoperability spec with the aggregator still says, Hey, it's required but it's, it's for me to be able to say that this is how far I support. Right. So if we have various levels of filters or sophistication or whatever, it may not be just binary on or off if they're right. People may choose to do different levels of it or something. Yes, that's that's that's where I that's where I have to push back because I don't like the idea of discovery through errors. Right. So if you're, if the spec says you shall support this, then I think it'd be, I think it's invalid from a spec perspective for someone to come back and say, I recognized it, but I'm not going to do it and therefore I'm going to error. That's not supporting it to me. Because you think, because then all you're doing is you still don't have the level of interrupt that we were concerned about. Right. We're just changing when you find out you don't have interrupt. Right. Was it at discovery time or runtime? You know, one, one might be better than the other, but you're still stuck with the problem of you don't have interrupt that we're concerned about. Yeah, I see. So. So, but, but John, so if, if, if you actually are okay with the idea of a subscription manager not being forced to support filtering, then I think your position has to be their optional. Well, my personal opinion is it should support source based filtering as the minimum. Right. Whether it supports more sophisticated filtering is a, is a, is to be a separate that. Understood. Yeah, I praise the wrong. Yes. Yeah. Yes. Right. So, so in my, in my, in my thing, because of my, my, my fear of implicitness. Right. I would say it needs to support source filtering on an exact, you know, whatever that prefix pattern or URI pattern, whatever, whatever that level, and we should make that level be, be realistic. But it should be, it should be required. Otherwise the degenerate case is always going to be, it's a fire hose, have a nice day. Okay, I'd like to hear. That leads to the W star problem. Right. If the degenerate case is, if there is no bar, other than here's the fire hose, people will, will, will, will, will, will sink to the common denominator. You know, I'm not convinced that's necessarily a degenerate or a bad case, but I understand where you're coming from. But I'd like to hear from other people on the call, whether anybody else has any opinion on this. I do.  So I understand what the degenerate case is. It's just that I don't. So from an interoperability perspective. So I can't see how this is a problem for implementations or use it while using an implementation that you have an, that you have an overly scoped fire hose of data and that's that's everything that that the customers asked for. And I think that it's required for the manager to understand the notion of source, which means we're talking about here, it is, if you give it a constraint, then the manager ought to ought to respect it, which is, which is for I don't think we're saying we're saying that you can that you can always get an unconstrained feed from a subscription manager. Like, like, if you are, if you're providing, if you're not providing any sort, any source here, then it's really up to the subscription manager to decide which kind, which kind of feed it gives you.  But then, if you are choosing not to constrain here, which means you're not specific in what events you want. And then it's really the manager that will go in and decide it. And if, and if the manager can tell what you want. But if you're meeting the source and that's probably an error. You lost me in terms of what you're advocating for. Are you are you advocating that it stays required or that it's optional. I think that I think the manager needs to. I think the manager needs to understand it. Okay, so require for the manager is what you're saying. The manager needs if you if you if you if you set the source, then the manager needs to understand it needs to process it but it can reject it. It's not I mean you can go and have a month and source and that but it needs to be able to go and reason about it. I agree with you that I think it should be allowed to say hey the source string you gave me is invalid, but it has to have at least some valid string that it would accept. Yes. Yeah. Okay. Okay. So. Okay, so I think as right. Why don't we do this when we keep it as required for now. And we can continue discussion through issues or something else or just for the next time. But at least now I feel like I understand Eric's concern and use cases better. At least I think I do. But I think we need to get more feedback because I have a very strong suspicion, suspicion that Remy may push back on this because I think he's doing the exact degenerate case that we're talking about here, but let's let's hold off. Now, as we're talking though it dawned on me. In the case of GitHub, the GitHub may actually have it be have source be required field right it's going to need to know which GitHub repo you want events from. And I think this may go directly to what you were saying Clemens about being able to error on bad strings in there. I think it's valid for the subscription manager to error saying sources actually required, even though the spec allows it to be optional from the center's point of view, a particular subscription subscription manager can say nope you have to send me this. Yeah. Okay. If that's true. Do we need a mechanism in the spec for someone to advertise that it's required or is that just something that they read through documentation trial and error. We could, since we have it since we have a metadata, we have a metadata service that describes the subscription managers, so we can probably put a flag there. I know we can. I'm just wondering whether we should. Because conceptual I could say hey that's a neat idea, but at the same time I also don't want to bloat our discovery spec. The source. We have a field that is about the source pattern right. Yes, but that we discussed. Yeah, but that that's not the same thing saying it's required. It just says hey if you give me a value has a look like this. I'm not sure that we need to have that expressed dynamically because I mean, you because you need to get the value from somewhere it's not that you show up and and. I think that's context that you need to have like you're not going to, you're not going to, you're not going to provide it or not provided based on some metadata discovery or, or, or some some dynamic value that you're getting back. Okay. Well, if we're going to, so that goes back to my thing to just make it explicit, right. So if we, if we change it to, if the manager side is required, and you say well the client side is required but you can put the star or whatever the magic is for give me everything or whatever I'm allowed to see or whatever that is written as, then it's explicit on both sides and you don't have any negotiation or, or anything you just have the I support that or I don't.  That is interesting. I hadn't thought abou