 All right, we passed the hour. Why don't we go and get started? Oh, one last person's I just noticed them Simon. Are you there? Simon? Oh, no microphone yet. Give me a sec. There we go. Simon, are you there? Yes, I am. Excellent. Thank you. All right, let's go and get started. Let's see, moving on, skipping over the AI. It's not sure there's anything too exciting there to touch on. Community time. So, this reminder, a little bit of time here for people who don't normally join the phone call or basically community members who want to bring up topics or questions or concerns. Is there anybody from the community who has an issue that they would like to bring up for discussion? All right, I'm not hearing. Can I ask something about the MQTT broker or how to work with MQTT with Bud events? So have the IoT device and I was just wondering if anybody was on the call knew how we intended to implement that or make use of it with an IoT transport. Is anybody doing anything with the MQTT? I know Clemens might be, but he's not on the call obviously. Anybody have any comments on that one? Kathy, do you, because you're so involved in IoT stuff? Sorry. Is it, are you talking to me, Rachel? Yeah, I thought that you might be familiar with, like you might be able to take this since you're doing a lot of IoT things. Oh, okay. No, not yet. Yeah, we have not started that. Okay. Yeah, so I'm willing to have a play with it. I've got an IoT device. I could start getting some sensor readings and seeing how it works with cloud events. I'm just not sure how the person that wrote the spec intended it to be you. So maybe I'll ask them in Slack next time. Yeah, or you can ask the question as an issue too, if you have a question there. Yeah, it seems like it shouldn't be challenging. MQTT carries a relatively arbitrary bag of bits inside. So yeah, I don't think there's nothing there that should get in your way. I wouldn't think it's just that they expected it to be implemented. Is that is should the device construct the message in the specific Jason payload or some other kind of payload on the device and then how do you handle that at the different end? So is your question about how it's represented within MQT or like how one would like construct the network topology? So how would you go about it end to end? What was the vision? Was it to encode JSON over MQTT on the IoT device and then have that broke it into eventually into an API gateway? The whole story from potential sensor reading to actually executing function. Yeah, so there is a MQTT transport binding is the name of the markdown. So that has how it would actually be encoded. I'm assuming you're going to have to have some gateway somewhere is to make sure that you bridge access from small devices to a trusted back end. Yeah, realistically, a large number of IoT devices are like stupid and old and emit fixed messages that you can't control. So there's like a lot of people who in the IoT space who build bridges of various kind to take what the field produces and turn it into something tractable and you know cloud events would be a tractable thing to turn it into. That sounds like a good idea as well. So maybe those go to an MQT broker and then from there it repackages the messages before sending them on. Yeah, but at that point it's just middleware, right? It's what? Middleware? Yeah. Good, Ellen. So I think to some extent cloud events is like a middleware format. So I could try to format the message in the MQT transport binding format on the device or I could try and send it to a broker and then send it on. From there we're expecting that potentially some service would run reading from the MQT TQ subscribing to that and then invoking I guess invoking the functions. Yes, so Kathy probably has more details on this but we have also when worrying with the IoT case said that the broker gateway could be the thing that actually does the first conversion of any raw data to a cloud event and that's considered canonical. That is an allowed thing, a lot of behavior. Okay, that's a good way of looking at it. That's useful for me. Yeah, I think that that's also the way you know you already there's like a gateway yeah you call it broker or bridge there's an outside gateway that you already does that and then send it to the cloud which has like an API gateway to decode that and then send it to the service platform. Do you guys think it might be interesting demo for a meetup or something like that to see data produced from like a node MCU a bunch of them going into cloud events triggering functions in the cloud? I would be hugely interested in that. Yeah, I would too. I think it would be great. Cool, all right let me have a think about that I mean feel free to reach out to me on Slack as well I think that could be quite an interesting demo. Did we make any progress with thinking about the RSS feed and how we were going to sort of do our next demo? So Austin I think you took an AI to start gathering thoughts around the next demo if I remember correctly, right? That is correct. I put an issue in GitHub which I confess I haven't looked at for a little while just throwing out ideas on what the next demo could be based on. There's a whole bunch of suggestions in there. I'm not sure if anyone's responded yet. And just so you know I did get a student to put up a Twitter like webpage so that we could technically continue with the Twitter like thing. If people want to leverage that going forward I'm showing it here on the screen. That looks interesting. Yeah, so is this reading RSS? No no it just takes post, HTTP post from whatever functions want to post to it similar to what Twitter did, right? Okay so you've made an API on the public internet and we can call this with our images? Yep basically yeah but whatever you know whatever text you want up top and then the image itself yeah. So it looks almost exactly like what we've had before. This looks interesting I'd like more details. Yeah I was going to talk about that when we got around to talking about the demos and stuff just not on the agenda for today but obviously we can talk about if we have time. Okay Alex back to your MQTT thing. Any other comments, questions on that? It sounds like you were going to do some investigation, right? Yeah I think I'll start trying to see how hard it is to build the message in the device or how much of the transport is defined or whether it's better to just let it go to a broker that then does a transformation into maybe HTTPJs or something like that. All right cool sounds good. All right next on the agenda is logo stuff and Austin I see you've been rather busy. Let me start back at the top here. You want to talk to where we are on this one? Sure you kind folks gave me two weeks to throw out a few other logo suggestions. I added a couple to this GitHub as well as another gentleman who came up with a kind of a clever idea around the balloon. So I also took that and did a few riffs on the balloon concept. So in there there's really only two concepts. There's our icon that we currently have with an updated font to look a little bit more modern. Those are near the top and then there's another concept with a balloon that was inspired by Kristoff and yeah so there's a few things in there. Each one is posted as a separate comment in that thread. Maybe if we like them we could just give them a thumbs up and figure out kind of what's what people are most excited about. Do you want to require people to only vote on one? You want people to vote on more than one? How would you like to work this little voting mechanism? It's totally up to you. Like the thing that occurs to me is that it might be too simplistic to just vote because there's a lot of overlap between these. So if we have like a three-second conversation about like I really like the spot and I really dislike the balloon or whatever it is then could we like get to one really quickly? Make it certainly try. Having a conversation about design aesthetics. I know. This will go well. This isn't going to rattle at all I'm sure. But I think we should I think we should at least take a few minutes to discuss it see if there's anything that's interesting here or you know there could be some good points that I totally overlooked. So maybe yeah if we want to time box it and just chat about it real quick. I'm totally open to that. Okay. I would say the new font looks great. Which one has a new font? This one? They all do. They're all using the same font. Okay. Except for this one which is the current one. All right okay. My only knit is I slightly prefer things that don't separate cloud and events when we went through the work to say that they are it's one word. That is an excellent point I forgot about that. So that's if we follow that pattern kick us off that first one. If you look at the original cloud logo you kind of squint and you see three balloons clustered. Wait you talking about this one? Yeah. Are you saying that is a good or a bad thing Scott? I mean it's interesting to mock that out and see what it looks like. The sea does get quite melded into the whole thing. The E is really obvious. I can see that very clearly but looking at it with new eyes the sea is a little it blends in. So the same thing is true here I believe. Do you have an idea on how to fix that? It would be just like moving to the left a little so you could make the sea go sharper at the end or? Yeah I'm wondering about something like that because I do really like the design or perhaps even adding a little bit more of a gap breaking the E from the rest of the cloud like the sea is broken or tinting the sea a little bit so you can see it's a letter. That is a very smart design very flowing. I do think my preference is more towards the cloud than the balloon. So keeping this general format? Yeah. Yeah I gotta be honest with you I don't I actually don't care. I think the current one is just fine. It's nice we just have we've got an opportunity to make a tweak maybe make the C.E. if the cloud looks slightly more defined. Yes I played with that a bit actually I tried to make it a different color make the E the same color and then use a gradient to kind of fade it into the rest of the cloud icon. I couldn't really nail it so I dropped that but I can certainly do another take where I just add in some more spacing around the sea. Yeah I think it would be interesting to see I mean I'm certainly not a graphic designer myself so I appreciate your skills on that. So I think what I've heard so far is people don't want to separate the words possibly move the sea out a little. People are okay with a new font. Anything else? Maybe the only other thing is that that tagline is maybe not have a double space they maybe bring it up by hand space in terms of this gap right here bothers you. Yeah maybe. Well so here's a question when we print out stickers do we print out the tagline or just the cloud events in the logo? It wouldn't work while on a sticker with a tagline. I'm not sure if many brands do that. Yeah because right now the stickers we have show just these two things right here they don't show the tagline. I think we could have a full on discussion about what a tagline should be so maybe we should focus on the logo itself. Yeah there needs to be probably a variation and then we had a discussion a bit a couple of calls ago about the t-shirt idea and I think this this middle bit would go really well on on a t-shirt maybe with the text on the back so we were able to split the graphics up into a few different assets and we finally decide what we what we need that could help people that go on to make that kind of merchandise. Okay so Austin I think you've heard a couple things about changing this stuff here a little you want to take another swag at it and come back with something? Yeah I could separate the C I'll remove the tagline at some point I think we should have a conversation about that tagline too just to figure out what what we think is best but that's a whole other exercise. In the meantime I'll iterate on this I noticed that one of the balloon graphics got some thumbs up so anyway maybe I'll yeah maybe I'll just take out the shot at the revise in the existing icon and we could chat about it again during the next meeting. Sounds exciting to me. All right cool hold on a minute let's go back. All right thank you. All right moving on Austin is there anything you want to bring up on the SDK work anything new happened since last time? I don't think you had a meeting. Nope we haven't had a meeting I'm going to send out something probably today. Been a bit of a challenge with the holiday this week so I'll send that out today and we'll coordinate something for next week before before next Thursday. So when you say something you mean a doodle poll or a summary note or what are you thinking? Correct a summary note as well as the doodle poll. Got it okay all right excellent thank you. All right Kathy is there anything you'd like to mention about the workflow meeting that we had on Tuesday? Oh okay so we had a good discussion on the workflow and also on the the Google doc that I drafted I think we discussed so what's the goal of the spec also we also the scope of functionalities and and also the what what are the approaches to for what are the approaches for specifying the specifying the workflow. We I think we are going to we decided we're going to add use cases a section of use cases to help better understand the scope of functionality and and and also like you know maybe to see what's missing there and we're also we're also going to help people present existing ways of doing the workflow from different companies so we're going to so the meeting is every Tuesday if you are interested you know a welcome to join that's pretty much about it yeah all right any questions for Kathy? Yeah quickly this is Leah Kathy I get I missed it actually is this a subgroup of of the serverless working group or or just a separate iteration on the topic of workflow? It is a subgroup of the serverless work group but I think it's a little bit independent of the cloud events although it's related so it's every Tuesday weekly but I'm not planning that we're going to you know drag that meet that weekly meetings for a long time I think you know once we have a good understanding of the use cases and the scope of functionality and then we drop to the specification I think we are going to come back to this work group I'm thinking we probably propose it and put into some GitHub and then the whole work group a serverless work group can review that and then yeah. All right does that answer your question Lee? Sounds good here it makes a lot of sense. All right any other questions for Kathy? All right cool thank you very much Kathy moving on we don't have any issues that need extra special attention as far as I know anyway unless someone can think of one off hand they'd like to bring up okay in that case let's get on to PRs so last time people asked for another week to look over the primer the first draft of the primer I haven't seen any comments added since last week's phone call I did add who was it a Sarah she added a PR a while ago about a quote starter doc and I realized that that kind of overlaps with the primer stuff that I did here so late last week I added some of the text from her PR into here because I thought it would be good to try to merge the two so hopefully if people like this general direction they'll close off that PR as well but other than that there haven't been any changes to it since last week are there any questions or comments about this as I said the last time for the most part this is just moving text around more than anything else okay are there any I'm sorry go ahead this is Rachel last time we looked at this there was a like one of the use cases was missing or all the use cases that were there before in this now no they were there it's just like I was I was going too fast here there you go it shows up it just doesn't show up automatically that click in the diff okay and I yeah they were there I just oh I guess I should point out I did call them um rather than use cases I call it value proposition because they didn't seem like use cases to me as much as they were trying to explain why cloud events would help in certain cases if people are bothered by the word or the phrase value proposition I don't know probably switching back to use cases it just seemed more appropriate to call up this but at the minor tweak I don't care either way but the text itself is still there cool yep all right um the one thing that I was hoping to see that I didn't was um not just design like a scope non-goals but just things that we've realized are anti-patterns like the embedding of a topic or destination into the event uh is that a separate pr or is that supposed to be this one uh no uh this is definitely just a starter pr I was hoping that people would I would notice things exactly like that that are missing there would be great topics to add that to that but we do that as follow on prs this is just to get something out there for people to start poking holes at okay I'll save it for a future action I'm okay great thank you but that definitely is a great topic to add yes anything that would it would explain to people who weren't part of the regular calls you know why we made the decision we did I think that's great stuff to stick into this document to help explain it all right any other questions comments concerns okay is there any objection then to heading this direction and adopting the pr all right cool thank you guys very much and please uh as Thomas was saying there if you notice things are wrong or missing or you can think of other ideals to add to there please uh do follow on prs now Clement is not on the call but I don't believe his pr has been changed in a while so in this pr if I remember correctly what he was doing was for the most part adding text down here that basically talked about how extensions don't necessarily have to follow the same pattern that we've laid out for how they appear when they're serialized that gives basically the out that we talked about at the face-to-face meeting I think that's the bulk of the change we just double check here yeah I think it's just some rewording here but I don't think actually changed a whole lot other than um hey drop the x for extensions it's just everything's a c e thing now I believe yeah I think that's the bulk of the changes now there was one comment that was made I think a couple of days ago uh Z Z pincer made a comment about um do we need to talk about htp headers and what do they know where do with them you know do they forward them on do they only forward on some and stuff like that and clements came back and talked about how this is really an htp thing and basically htp says you have to forward everything on however he did agree that we should be clear about that on the spec and I think that would be a good follow-on pr because I think that's true regardless of whether this pr exists or not so I think that'd be a good thing to write down in general so I think we can follow it could address that in a follow-on pull request um so I was going to make a note of that if we did adopt the pr but are there any questions or comments on this one do people need more time to think about it can I have like three more seconds to read through this of course my phone to me that's the key line right there okay I'm good with this okay do we other go ahead sorry and see hi doc do we not often see x also used as a prefix for custom headers should this be xce rather than ce so there was a big discussion about um how htp has dropped the use of x in their headers recently or they discourage it it's still allowed okay oh obviously it's allowed yeah but it is but it is discouraged um I can read the rfc or itf whatever it is uh paper on i think was mark noddingham wrote um but I think that's the reason that um that clements dropped the x was because htp was pretty much dropping it as well but but this line but the sentence right here basically allows an extension to add it if they really wanted to any other questions comments so the examples are things like event time event id and um was it thomas that said that we must we mustn't put topics within the cloud event but is this somewhere where it could be in this extension oh yeah I mean obviously people are allowed to define their own extension if they wanted to define a topic extension they're they're free to do so yes all right any other questions all right is there any objection to adopting this uh as a question on the last comment not on this pr um how why would one use an htp extension for a topic and how does that destination differ from the actual htp path at which you're posting the message I assume that question is more directed at alex yeah just trying to understand sorry can you repeat that thomas uh so there already is a destination htp spec it's the the path component of the htp post um so i'm curious where that would differ from the actual or like why a topic extension uh and how you reconcile it between that destination which is the path destination and the htp post so you're saying I think if i'm hearing you right that if a message is coming from a use the example again a kafka broker that is reading events from a um a topic partition then retransmitting them to an event gateway that it should send a htp path of the um the topic that it originated from I see so you're using topic as a source information not as a destination information which I think is part of the confusion um so like I I've personally been militant against embedding a topic as the destination um just because it means that the event can't be shared or put in another place yeah so I I was trying to think about this how I could do it in an open vass as a use case and doing it backwards in effect um we know where it came from but where it's going is abstracted away like you say you can then use that in multiple places okay thank you for the clarification all right cool thank you any other questions on this one is there any objection to adopting it all right done all right klaus I believe you're on the call would you like to talk to your pr yes so that was my action item after I presented this issue in um at the um face-to-face meeting so I was styled in um and I think the conclusion at the face-to-face meeting was that we can remove the event type version um which I did in addition I just added a sentence um to the description of the schema url that um if the schema changes then also the schema url should be a new one so to reflect the new version any questions on this one all right any comments concerns before I ask the question do we have more emphasis to event type version in other meetings or stuff I don't see them being updated so he went through and removed it from the jason format uh document I think I think we have it in others don't we do we I don't know I did it get cloned and then a grab on the event type version didn't find anything else but find anything just let me know yeah if we miss one I'm sure we'll catch it or we'll find it and do another pr all right is there any uh concern or our objection to adopting this pr all right cool you guys are very quiet today all right um um well I want to just take a minute because I had a I had a couple conversations offline with some people about extensions obviously related to the next two prs that we're going to discuss and I just wanted to get uh or have a brief discussion to see if everybody's on the same page relative to extensions um because I'm not sure everybody is and I want to make sure we all have a common understanding because if we don't have a common understanding then I think we're going to continue to go around in circles for a while um and so I'd like to just take five minutes to prove you talk about them if that's okay um the first is I wanted to make sure that people understand that when we talk about what is an extension uh in my own words basically an extension is anything that is not specified in our spec dot md file okay if it's not in that specification or or I guess I should say if it's not specified in one of our formal specifications like spec.md then it is then it is an extension so for example the extensions.md file that we have obviously those defined extensions but if a vendor like say IBM decides to add a particular attribute someplace inside the cloud event that is also an extension it's a vendor extension but nevertheless it is still just an extension so anything that is not defined and agreed to by our working group as part of our formal specs is an extension is that consistent with everybody else's view yep yep okay cool just want to make sure now the second point is location does not matter and by that I mean if you look at this example here on the screen right you have a chunk of jason and you have two chunks of we have two properties here in red is apartment and is married now in the past or sorry in our in our spec we talk about extensions we have a you know a bag as of right now called extensions so I think there might have been some confusion about well what if things appear other places like for example outside that bag and I want to point out here that again it does not specify as part of our spec it's an extension and that's true regardless of where it appears so in this particular chunk of jason if the spec defines this schema here then is apartment and is married are both extensions in other words location of the extension does not matter they are still extensions is that consistent with everybody's belief like we can make that the case but it's going to present a problem for strongly typed languages and so I don't I don't want to just say like like we can we can like agree that that should be the case but we need to come up with a solution for how we're going to implement that right this this doesn't talk about whether we want to allow extensions everywhere this is just saying if you don't say otherwise and they are allowed they are both of these things are called extensions it my point here is that there isn't a different word for is apartment versus is married they are both extensions is my point okay but they're different extensions they are totally different extent well yeah yeah yeah they can't be different extensions or someone could say I want me to find these these things to go together that's out of scope for the discussion yes but they are both just extensions so extensions can have scope right you yes you could definitely say is apartment is an extension and if you use it it must appear under address you can definitely specify as part that is part of the definition of this that is definitely true yes okay thank you can we also go ahead Kathy yeah I'm thinking you know um so we need to be clear on what what will be in the spec and what will be in the extension so so if you say like you know vendor specific things are in the extension should we have like a vendor specific spec on the vendor's extension like some extension spec which is for you know for vendor to put their extension there um I just don't think you know is is quite right to just put any random things into the you know into the the events you know anyone just just can put anything there without clearly defined it defining it all right this is Tim um so the point about strong a strongly type languages is a good one and so we've got a thing set kind of like this in AWS AWS events that come from all their AWS services and there's a router and so on and there's a lot of them I mean there's you know there's some huge number of services that he met them now and the number per second that's flowing to the system is is absurdly huge um and that's been one of the central problems we've had is we got complaints from customers saying well I need a schema so I can just you know map it into into my Java object and that problem has turned out to be really really hard and not only have we not solved it I'm not even convinced there is a good solution because obviously at some point you're going to have a data field that actually has the the source specific payload in it and um you know unless you insist that nobody is allowed to contribute data and unless they provide a you know object binding libraries for Java and go and .NET and and so on you're kind of stuck and so I'm just I'm not saying that's not a not a good idea I'm just saying it's it's a really hard problem one thing we did is so for the top level wrapper fields like we're really super fascist there's only like six and they all have to be there always and no you can't ever put anything else in there and so on and so forth so at least we've banished the the irregularity and service specific stuff down to subsidiary elements I'm not saying that approach is is optimal or that whether one that you know cloud event should take it's just some some of our lessons yeah again I just want to point out that for the purpose of this discussion I was ignoring the possibility of of the specification of say this schema banning extensions in certain spaces I would my point here was just to point out that both his apartment and is married assuming they are allowed per the definition of the schema that these are both called extensions okay so I have a follow-up question um so IBM wants to include these extensions is it or like is it still compatible if another person supporting cloud events does not support those extensions yes because extensions unless otherwise specified should basically be optional for a receiver to understand I think my question is you know if we can just put any random you know key value pairs in some random in any place so how should the I mean the I think they could cause quite some issues right because it's apartment there is there is cause for confusion happening isn't there so let me make sure we're focused on just with the one aspect right keep in mind I'm not focusing on whether we should allow extensions at every spot in the hierarchy that's not my point here my point here is just to say that if if the specification allows an extension at his apartment level and it allows it to be where is married appears then they are both called extensions okay then can we change the subject to be the one like should this be allowed because that seems very that seems like a very natural question to ask I I agree and I I I try to remember if I actually get to that I think I think that's going to lead into the next PR discussion my bigger point here was just to make sure that people don't think of extensions that we define are somehow different than vendor extensions they're all extensions and in particular whether extensions appear at the top level or whether they appear inside of a bag as long as they're both allowed they're both still just extensions that's all I was trying to the the gotcha though so I mean in formal logic yes the in anything that follows an if statement where the condition is false is true however I don't think anyone has proposed that there's more than one place in a rendering to have an extension so it's really hard for us to follow because I can't call this an extension because I don't all I see this is non-conforming data and I think that the idea that I disagree with the premise that that a cloud events are JSON cloud events have a JSON representation and b I disagree with the idea that just because we allow extensions that we don't understand means that we allow them anywhere in any representation I agree as I said this isn't getting into whether we want to allow them everywhere this is just based upon the conversations I've had and the the the terminology that I've heard people use people were putting extensions into different categories of extensions and and in my mind we need clarity on whether that's something we want to propagate going forward because in my mind an extension is an extension is an extension as long as it's allowed to appear there I don't care who created it or where it appears it is an extension and it's not something else we did some discussion about you caring or someone for scaring where it appears and that was because we were just looking at the headers weren't we let's talk about where it appears in a minute okay the other thing is Rachel has a comment here that I don't know if anyone's spoken about yet about how we would cover this in a strongly typed language yeah I I made that comment after I brought it up in conversation and then I don't remember was it Tim Tim also has this problem I'm not sure like I know Doug that you want to isolate the conversation to what do we call this but I think a lot of our minds are jumping to the implementation problems that we see with this and that's fine and all I'm asking is patience we will get to that I just want to make sure that that there isn't a different word that people want to use right vendor extension is no different than extension that's all I'm trying to say okay we move on to the part that I think we're all jumping yeah okay let me go away with that extension versus vendor extension because I could imagine not everyone producing cloud events will be a vendor to me the word vendor should be dropped from our vocabulary when you talk about extensions they are all just extensions I think I agree with you okay I think you know um I would have to second what Thomas just said I think you know um we should not you know allow like it will be confusing you know um for the receiver if you know anyone any of the producer can just put any string in any place okay Kathy hold off on that we'll get there in a minute we'll get to the location in a sec hey Doug I think you're getting such engagement on this issue because you've done such a fantastic job of finally laying out what an extension is so I hope that this makes it into our github at some point because it's uh it's a very good explanation well I I do think that when we finally get all we all get agreement on extensions where they can be and stuff like that then yes I think this information should go into the primer someplace so other people can understand our thought process agreed yep or extensions on d or extension and d yet more than there yep someplace basically yes okay so one last point before we jump to what everybody wants to talk about which is where do you want to allow them um for the moment give me some latitude please and let's say our specification does allow send sms as a property at the top level and our jason rendering just give me that for a minute we may not allow it I understand but for the moment let's assume we do my point in this part of the discussion is to point out that if we allow extensions here and we allow extensions in what we currently have in the spec which is a bag called extensions these are both extensions and technically there's no difference between the two does that jive with everybody else's understanding well one huge difference could be that it's expected that every value inside of the extensions bag gets forwarded and everything else gets dropped I suppose you if you were to add language to the spec that said that I suppose that could be true but barring someone going out of the way to say that I'm not sure that would be true no I think I think it's right because um if I don't have to support if I don't have to support all extensions then I might treat different like I assume that it would be the case that I would drop the extensions I don't support and I would just pass through the extensions bag yeah that's true well I agree with that too yeah boy pass through the extensions bag or pass through the extensions you know about there's two there's two very different things I would I'm suggesting like this is my intuition and we can talk about whether or not this is anyone else's intuition and so say you have so you are supporting a new extension that includes send sms as a top level key in value I'm not supporting that extension I've never heard of it before so when I get the event I drop that but I want to be as compliant as possible so everything that's in the extensions but like underneath extensions I will just pass through so let me ask you about that if the specification makes it perfectly clear that people can add top level things and they can add extensions under here why would you choose to only forward one and not the other because I have no idea what that extensions I've never heard of that but you've never heard of enable logging either but I know that that is going to be like this this is the point about strongly type languages I know that that's going to be like a key value pair like bag and so I know what to do with that and I don't know what to do with any random other piece of data that you send me so I don't have so I disagree with that because as of right now extensions is basically just a bag it's a key with an object that is no different than this it's quite different okay so as send sms like right now it looks like it's a bully and it could also be a string or it could be anything in the world and I have no idea what that is and that's that's the like heart of the matter for me but I could do that as well just as easily so why is it any different okay so for each so for each thing so for so for if we just go through each one of these keys and values uh so like cloud of insversion I know what to expect that I expect it to be a string for source I expect that to be a string for extensions I know that's going to be a hash right I know that that's going to be like we've been calling it a property bag but I have a clear way of what to do with that thing when I get it send sms I have no idea what to do with that when I get it I don't know what this is you're going you're asking me to take a strongly type languages and make it and make it a like a not type language and that's going to be a huge implementation problem for me elaborate when you said send them as when you said you don't know what to do with sent sms which so the bottom the bottom top level property the second sent sms I don't know what kind of thing that is and it's going to be hard for me to deal with why is that any different than the first one because the first one I'm going to well it is kind of still a problem but I'm just going to make everything a string I'm going to pass it through but you can't um so dog also logically group something together you know will be easier for the receiver to decode it or to handle it rather than we just throw thousands of you know could be like hundreds of random you know um whatever this as send sms or other things at the top level that would be you know hard for the receiver to handle to handle okay if we have quorum on on how we're defining the types because there is an issue open as well I think is it yours Doug that's suggesting everything should be represented as a string on the other end of that when you're decoding it into strongly type language how you know what it is and then whether we have to embed a schema to support it too so I I'm fascinated by this discussion and to be honest it kind of hurts my head a little because all the arguments for why this bottom sent sms is hard for people it should apply to this one and yet people are saying it doesn't and that's mind-boggling to me and I don't want to rattle on this on the call here because I'm not sure this is the best place for it so can people have comments about why these two are different into the pr about removing the extensions bag because I really don't understand that can I make a stop yeah we have to treat all of the other properties top-level properties as untyped as well so to be able to bind all of this struct and then just because of the single field or additional properties somebody could provide so you cannot be type safe with the other stuff you have to play it safe and use the like open key value map for everything yeah that makes it really difficult for the implementation it might be easier having the known fields at the top level when it comes to thinking about our language like go for instance and then having this part unmartialed conditionally if you're interested in it rather than having that that data all mangled together okay because in goal you can definitely do this without any problem I've done it myself that's why I'm really kind of confused not the question whether you can do it uh it's how usability trivial that is and that's not trivial uh especially to do it in a type safe way okay performance impact as well when you start I believe I mean correct me if I'm wrong when you start to get into the and it's not just goal of interfaces or in dot net using dynamic and things like that okay so can I get you guys to add comments about that to the the pro request about removing the extension the bag because I think it'd be useful to have that discussion in there and I like I said I don't want to rattle on this on this car right now because I don't think it's the best use of time yeah I would like to just add one more comment so for the extension right I'm not uh I'm just thinking why do we just have a generic names extension I think it would be better to have multiple different categories of extension right so that you can we can have either a type it so for one type of extension you know we can see we can give it whatever the name right so you know what kind of type if we want to use it or we can just skip it right um instead of so everything into your suggestion would be instead of having top level um like does that does that end up becoming something analogous to this where instead of like send sms that like at the bottom that key would become something like um uh this like IBM dash uh sms extension like something like that and then that can be a property bag of whatever it wants yeah something like that IBM extension or like you know google extension something like that or some other meaningful extension of people knows how to use it and also it's kind of it's better to be defined so that of course when they're specific right you do not need to find the it's already uh self-explanatory that's the other what's the difference between that and putting IBM under extensions or just saying the IBM dash and sms and get rid of it well Doug you still don't understand the hydration problem the hydrate well I'm sorry I'm sorry for that top level thing there let's do this how's that right but that's that's easy for one key but now make extensions have an IBM bag oh I see what you mean yeah that would be better you know I believe that's what gath you are saying but IBM extensions under extensions yeah yeah because I mean I don't necessarily like the word IBM here because one of the reasons for extensions is like something that you expect a broader platform like you know we look at our examples um we have things for tracing for uh sampling for uh we've talked about adding jaw authentication claims these are things that we like we expect IBM or Google or Huawei whatever will pioneer but they're explicitly at least known extensions are doing it because they expect others to do it I agree and that's actually one of the reasons why I wanted to remove the extensions I think itself for the exact same reason people wanted to drop the dash x on htp headers because the minute say send sms becomes a valid thing we want to put as part of our spec if it's under this bag everybody's gonna have to change their code to support it in two different places at least for a period of time so remember cloud events is not json so everything you're saying does not apply to proto I understand but I but so we can we can smooth some curves we cannot pretend that we can ever avoid them great I'm not I agree this is I am of the belief that our spec as I think Clement's first pointed out is more of an info set spec and then we'll have different serializations for different things like proto versus json and they may look radically different have very different ways of dealing with things like extensions yeah and so it has no extensions it just says that you can have extensions there is no extensions bag anymore I thought and then you're talking about the rendering in various languages yeah well as right now I think we do have an extensions thing in our in our info set the thing I worry the most about with all of these extension talks is people starting to put the the vent data into the header which is against what we're actually trying to accomplish with cloud events I totally agree with that I did that exactly I was gonna get to that discussion at some point too yes one more point here if we do have the last send SMS to as a top-level property and then cloud events three three point five whatever as the send SMS property as a top-level official property and not an extension it's gonna be held for promoting this for with backwards compatibility as in I had an extension which I did the send SMS field as a billion and now cloud events is defining your send SMS field as an official field and it's a string or it's the phone number or something like that at least if they're all in the extensions bag yet we might have to support you but I won't yet new version of cloud event conflicting with an extension already implemented okay so we're almost out of time tell you what I think this is a worthy discussion and what I'd like to do is send that a note asking for people though who who are interested in this to talk offline about this because I don't think this is the best phone call for our best venue to discuss this so I'd like to send that a doodle poll to see who's interested in talking about this in an offline discussion is that okay with people that way we can continue to come back with a proposal can I can I make one request additionally can we write down somewhere what we like the formats that we intend to support because I know from talking with people that we at one point we said we wanted we want this to be implementable and for example proto and jason but I'm looking through the spec now and I don't see anywhere where that's written down as like one of our goals like is there so like that would be really helpful to inform these kind of conversations I think yeah I think we've been kind of going with the assumption that if someone wants to support a particular protocol or format then they write a spec for it and that's the way we say hey these are the ones we support because they are there's actually spec for it so I'm expecting at some point someone's going to come along with a proto one is that not true Thomas all right yeah we're talking about it in general there's still some struggles and ironically extension is one of them there you go it's not for the reasons you expect it's because we can't have something that includes scalars very easily okay and I actually think that discussion the camera who brought up the the issue I raised about should everything be a string may actually play into this in some fashion right because if we decide that's easier for everybody that may make some of this easier going forward well it makes it encodable but it defeats the entire purpose of proto in that once you have a proto for it you have a library for it that is like useful and meaningful uh if you then have to layer on top of the proto based library a semantic parsing library you might as well not have had proto to begin with understood um but no the big thing that we're struggling with is that proto can't support a variant um so that that type of variable in our infosa is incompatible with proto get a real one will you sorry all right um I believe we're basically at a time here so let me just quickly go back to the uh list of attendees um Jurgen are you on the call what about Ryan are you there yes I'm here Louie are you there Eric yep here to me okay Neil yep Neil I think we lost Neil uh Gourish Gourish are you there okay Heinz I don't know who Heinz is I don't think we've had them before what about fraud yeah I'm online is that a fraud or Heinz fraud no sorry this is a Heinz I'm a Heinz Schafter I'm gonna start to try and join these calls I'm uh calling from my solar systems okay great do me a favor can you go to our agenda doc and make sure I split your last name right and put your company name in there so I can get you on the attendance roll absolutely thank you very much and Gourish are you there or Neil okay is there anybody I missed okay just to finish out the last discussion we're over time but I will send that a doodle poll assuming everybody's okay with that to try to get some offline discussions going send it on the email or in soccer I will send I will send that email to the cloud events mailing list okay thanks excellent thank you doc what we're gonna have another another me offline meeting oh yeah we gotta have lots of offline meetings you know what group and not an event now we have another one well yeah I I'm if no one shows up then we can talk about on this one it's it's a you know it's really up to you guys I just thought we we don't want to necessarily have a deep dive on this particular call this one's more for a resolving poor request yeah I think probably you know um yeah of course we can have offline call but you know post comments on the on that um was that that's pr yes another way yes that's definitely the preferred recording for all the calls please I could have done the last three or four meetings and it was rather hard to find the recording yeah when I talk to those guys who manage their recordings I'll try to make sure that they they pick up all the uh the non-regular ones as well that would be perfect thank you all right cool thank you guys very much and I apologize for running late but it was a good discussion thank you thank you bye bye thank you