All right three after why don't I go when I get started um let's see in terms of ai's The only thing that we want to point out actually never mind. I'll point that out later If you have an ai, please get to it when you get a chance. There's the list is shrinking those. That's all goodness About the face-to-face in Shanghai We do have a list of proposed topics in a Google doc so when you get a chance if even if you're not going but you think there would be a Topic that isn't listed there that you think might be a good topic to talk about please feel free to add it I am planning on setting up a call next week for the people who will be there to discuss Options for what we're going to discuss and who wants to talk to which topic If you do want to participate in that please just add your name to the mailing list or to the Google doc and Include your email in case I don't have it. There's one person in there I can't remember their email address unfortunately Now we I am planning on doing a phone call this Friday at 3 p.m Based upon the little poll that I sent out for a brainstorming around the next possible interop type event Do you have a Google doc here? With a list of ideas nothing is set in stone at all right now is just sort of my rambling so far So please if you have additional ideas or suggestions, please make them in there Even if you can't join that call or don't think you're going to be able to participate in the event itself If you think you have a good idea for us to look at please add to the doc But according to the as I mentioned according to the doodle poll looks like 3 p.m This Friday eastern time is when we'll have the phone call So I'll send that an invite to the whole mailing list. So anybody's free to join even if they didn't put the name on the doc Anything about those two events that people want to bring up any questions or comments. All right, not hearing any stickers the new logos that Austin put together for us are finally available in the cncf shop and So they are finally in stock and I was given a coupon code So so I was able to order 200 of them this morning. Hopefully they will arrive relatively soon and I'll be able to bring those to the coupon event in Shanghai as well as Seattle and hand those out to not just other people but to you guys as well So you guys should be able to Share that with your family and friends because that's always exciting. So just want to share the latest status on that I suppose if you guys have a conference that you'd like to give those out to before those events Jump me a note that I'll do my best. Maybe ship some off to you Step to you or you can wait to the conference. I will bring the full stack available To those conferences All right. Any questions on that? All right, community time. Is there anybody on the call who's not a regular Person on this phone call from the community who'd like to bring up a topic in general All right now hang anybody. Let's keep moving forward then. I don't see Austin on the call So I'll try to update what as far as I know what happened with the SDK group I believe we had a phone call last week And really for the most part we talked about the GitHub repos or maybe that was actually before Anyway, I think from our last Thursday phone call. We agreed to go ahead and create the repos one per language So I created a Python C sharp Java and JavaScript repo VMware wants us to just migrate the resisting goal line repo over so they're working on whatever I Think internal approval process. They have to make that happen. So hopefully that happened fairly soon But then we should have what is that five different repos all set up. I Need to be given the names or I'm sorry the GitHub IDs of people who would like to be made admins on those Because as of right now, I don't think I've made anybody an admin And I'm definitely not doing all the work on all five repos So I need you to send me a note or ping me on slack with the GitHub IDs of who you want to have admin access on there At some point, we should probably talk about the governance of those repos but for right now We'll leave it a little bit loose just to get the things Bootstrapped a little But anyway, we should probably talk about it at some point Any questions about SDK work or anybody who was on the ST a call can they think of something that I forgot to mention All right, not hearing anything moving forward Cathy. Is there anything you'd like to mention relative to the workflow? I'm sorry workflow subgroup Not really. Yeah Okay, all right in that case. Are there any questions for Cathy? All right now hearing any moving forward then All right PR reviews a couple on here, which should hopefully be fairly straightforward. Let's see what we got here first one All right So this one I wanted to just this is just the minor typo everything else in this list was singular So I decided to make admin singular as well the bulk of the PR is I wanted to update our owner's file to be a little more consistent with Owners file that I've seen in other projects In particular, this is just basically this at the admins and I which I still keep so I still have the admin section But I wanted to do was add in a prover section now even though we don't have a formal list of approvers Per the normal get-up process What I did do is add a comment here pointing to our spreadsheet Telling people to look at the voting rights column in there and that will give them the current list of in essence approvers Meeting people who have voting rights since that's the closest thing we have to that. I don't think this is a change in our process I just wanted to document what we're actually doing Yeah, it looks good to me. Okay. Thank you, sir. Any other questions or comments on this? I have a question when we talked about this before I thought we're going to cover How we like what we do if one of our current admin sleeves Yes, and I actually did that this morning and since that I think on a previous phone call We talked about opening up an issue to make sure that we add additional documentation to cover that I open the issue this morning I have not had a chance to actually execute on the issue yet, but that is on my to-do list. So, yes Yep All right, any other questions or comments? All right, any objection to adopting this poor quest? All right, not hearing any. Thank you guys All right next one This was also mine a couple things here one is We're not really a new effort anymore. So I just wanted to clean that up Well, I was in here making the other real changes, which is we are I Wanted to make it clear that I'm sorry, I got distracted there. I want to make it clear when we actually became a sandbox project Mainly because and this is a strictly selfish reason Every now and then somebody pings me about our status what we're doing or when we became a real project and I Life me have the hardest time remembering it and I figure other people May have made me the information about when we became a sandbox project so I wanted to include a link to the Google doc for the TOC Meeting in which they actually voted to make us a real sandbox project and it was a May 15th So I just want to put that information in there That's really the main purpose behind this PR So that other people can reference it if they need it any questions on that comments Any objections to approving the only yeah, hey Doug This is and the only the comment and it's kind of a dumb comment I apologize, but I think we're gonna try to change sandbox to cloud native sandbox We'll kind of in discussions on that right now But since you're making changes if you want to just instead of saying sandbox a cloud native sandbox in front of that And that should cover cover you for going forward with the CNCF sandbox. So you want cloud native sandbox? Okay, I can do that. Is there any objections to making that change along with everything else in the PR? So it would appear right here Doug you fix the the columns I mean the 80 column thing Now the URL the you've removed a bunch of text on the line 18 and now line 18 is very short. I Don't mind short. I mind long, but if it makes you happy, I will try to make it look a little more consistent just for you Scott it has to be aligned Anyway, I'll work on that Scott any other comments or questions on this any objections are approving All right. Whoops. That's good. Sorry, Scott. That's got Okay, approve. Thank you guys very much Uh Kathy this PR is yours. I believe There we go All right, you want to talk to this one Kathy? Yeah, this is just a minor twist for last meetings on action item just to clarify That you know if the primary representative cannot attend the meeting and He he or she can have a delegate And that attendance will be counted Yeah All right Any questions or comments on this one? English is kind of hard in this the they in line 71 doesn't it's not clear if it's the delegate or the pair Should we change it to I Don't want to say company or individuals may kind of work verbose I Think here the day is same as the lens 70, you know, they obtain right that's not changed Yeah, I think I think Scott's Worried about it because you introduced a sentence in between the two when they're right next to each other the day was a little more clear Am I right Scott? Right. Originally the day was the a single person. Oh Actually was company, but you don't get that so definitely need to clear that up then Also columns Kind of kill me any suggested alternate word there then instead of they participants or entity Yeah, I was gonna suggest entity Okay, it works. Okay Kathy, are you okay with that? Yeah, so I just change that to the entity. Okay Yeah, if you can give you that that'd be great Any other suggestions or comments on this? I'm sorry someone speaking as Jesse so not to nitpick, but I think that his her could be there Kathy you want to get that one too. It's a little cleaner too Kathy you okay with that one too? Yeah Okay Anything else? All right, any objections to adopting this PR with those minor wording tweaks. All right not hearing any Let me make note of that and columns busy. Yes Scott. I got you So scathing if you can just adjust the columns to make Scott happy. I appreciate it Okay, here we go one that's a little bit meteor so if you guys remember correctly we wanted to define a bar for adding new Extension attributes to the extension document. I believe last time we talked about this It may have been Thomas who suggested that We actually have in essence sort of sponsors Meaning at least two voting members of the group say that they Are willing to say yes, we should adopt this as a well-known extension That doesn't mean that they're necessarily going to implement it themselves It just means that they think it's worthy enough to be included And I believe that's in here um Yeah, I need to have at least two voting members and the if the if The author of the poor request is a voting member they are allowed to be one of the two as well That way we don't have to worry about people playing funny games Give me about like other people submitting PRs, you know on behalf of other people just so they can vote Anyway, I think it's been out there for at least five days or something like that Any questions on this or comments go in once Any objection then to adopting it? All right. Well, that was easy. Thank you guys All right, Kristoff and now I know Kristoff There may be some open comments on this one So we may not be able to approve it today But I did want to get people's general sense about the direction because I think it was a very interesting approach And I just wanted to bring it up for the group. You want to talk to this one? Yeah, I apologize in advance. My two year old is here. So he may talk in between Try anything if it's too annoying. Just stop me So this came from a couple of problems specifically for HTTP a problem is that names or headers are not case sensitive So we have a problem if you want to convert a case sensitive attribute name to a to an HTTP header So we already had a What I drew naming convention. So I basically in this PR I sharpened it. So maybe you can scroll down The other file Out of the other file. Yeah Yeah So that's already said we should use camel casing for example, so I made this a bit What I say it more strict And saying that you should only use alphanumeric characters and it must start with a letter So we had before as a goal that the attribute names should be Okay should be available for or should eight integration of common programming languages And I think like if you limited to alphanumeric characters, we actually get closer to this goal So it's really well, it takes away a lot of freedom like okay But then we are kind of sure that we can use this name in all programming languages And we also open up the possibility to convert between cable case and snake case or for HTTP converted to non case sensitive ways so that that one I did then in the upper file. So I made new rules basically for HTTP headers where there is kind of an existing Convention that you separate words with a dash. So I made that the rule for the HP Okay, that's it on my side. Do you want to mention though the one that's a little bit weird. Oh, yeah, that that one so Follow this this rule For longest rule strictly means that for example ID will be separated by two dashes which is also not how you would do it in the HEP convention so we could think about making exceptions for example ID and URL and so on But I think we can discuss this Yeah All right, any questions on this one. I thought it was kind of interesting approach I wanted to get it out there because I know this is a big topic for people. I Like it I think the only concern that I would have about the special casing is we would have to make that list huge up front Because adding to it later would break version Changes later. So the earlier SDKs that don't know about the special named ones wouldn't know how to deal with Those later So if we're gonna go that approach, we should find every Special case that we could possibly want up front To avoid breaking the the SDKs later Just that a curiosity on that Would it be sufficient for us to say that acronyms or abbreviations Are special and leave it that or do you think we'd actually need to list them out I? Would imagine that we would probably need to list them out Because again, if they're all lower cased By you know, whatever means it'd be hard to actually tell If those letters were meant to be an acronym or if they're just actually a word You're right. I forget about going the other direction. Yeah Right any comments for other people? Yeah The so I'm running into the same problem yet again now with in another context with trying to get mqp and HTTP aligned We'll have the same problem and I Think ultimately from a so this mapping from with Injecting the dashes and pluses. I think that's gonna get ugly very fast In practical use because It's not entirely clear what that means and then you may may Have mixed mixed use cases where so I don't want to make it too complicated I would probably I would probably rather go and make our Constraint our names more That we use in the specification and say you can only use your lower case Because because right now we use camel casing because it's pretty and that's the only reason But we can constrain ourselves and and making things case insensitive is a giant deep pit So if we can because case folding and then what is a character and are we constraining ourselves to ASCII? And if we're not then you need to have eight their territory then you're in case folding Scenario, so I think if we're more could if we're more restrictive About what we allow and say you can only use lower case And you can only use Effectively ASCII Characters Then we would make that easy for everybody So just to be clear that would mean In particular to say the Jason in format all the Jason properties would be lower case Yeah, everything would be lower case every everything everywhere, but with that we don't have any problems with case sensitivity right and We would simply I mean you would lose the prettiness of having a word separator But I'm not sure how terrible that is Any comments This is Tim I that I think that's probably a good idea anytime case folding can possibly be avoided It should be it tends to be a performance bottleneck in some languages because they try and be unicode complete and locale sensitive and so on We did that in an AWS CloudWatch events. Everything's lower case and it's we've not regretted it Doug I think you might not be on mute. Was that just because you're not on mute or because you wanted to say something Okay, maybe it's not anything anybody else have a comment Yeah, I wanted to clarify that this is alphanumeric characters only so I think case folding If you really like only that those base SK letters It is not as bad if you as if you have to fall full UTF 8 or you have 16 Actually, it sometimes it is in a Turkish locale the upper case of lower case. I isn't ever case I something different And like languages will try and look at your locale setting and do the right thing So just don't do it if you can possibly not do it Okay, any other questions or comments? I hear two different alternatives being proposed one is Is whether this PR and another one is just lower case everything Anybody else have any feedback on which direction they prefer or an alternative? I Must rather have it be case insensitive. Is that advocating for the Yeah, okay. Thank you. Bye Anybody else I'm gonna pick on somebody here just because I can Austin I'm gonna pick on you as sort of the leader of the SDK subgroup. Do you have an opinion on this? Hey, duck. Hi everyone. You caught me writing emails. I'm totally tuned out. I have an opinion I just I don't know what that is because I wasn't paying attention to this. Okay, fair enough. At least you're honest about it. Thank you Okay Okay, let me pick on somebody else than just for fun Because I know the background and in some of these protocols like this Matt Rikowski In your experience with some of your other inventing type of protocols and stuff. Do you have an opinion on this one? I Mean, it's better to be prescriptive on the on the specification side and post things in the authors of these events because if people bought into the spec and they're gonna they they're interested gonna author the spec Why suffer any issues in terms of case folding or having to add things to your pipeline to to deal with, you know Transfer in case Unicode all the things why inject other tools in the pipeline and things don't need to if people bottom the spec They're going to do it with the more prescriptive things to make processing more efficient Okay, thank you sir Anybody else want to comment? So hey, this is Jen. Um, this would indicate a spec version change. Yeah Well, we're not at 1.0 yet. So we can make this change freely Okay, so you won't bust anybody. That's already Programming to 0.1. Yeah, my understanding is and again new in yeah, you're on 0.1 at the moment Yeah, yeah, well, I wouldn't say we won't break somebody because we would But it's okay that we break them because we haven't reached a major version of it yet And until you reach a major version of it, you can break them all you want. Okay. No, that's fine I just wanted to understand your policy. That's cool. Yeah All right, I was just looking at the HTTP headers Specification looks like there's an RFC profile there to specify case insensitivity so that might point to prior art Yes, I think somewhere in our spec we do talk about ACP headers being case insensitive as well Actually, it has it right here line 167. So yeah, right Klaus. Would you like to say something? You said something in the chat. Okay In the case that you have case insensitive names, you still would have some kind of word separator like the minus So also in that case, you would somehow need to mark up the map entries So Clemens, you want to take that one? Was there a question for me? Yeah, it's basically saying what if there are dashes in the in the property name, I believe, right, right, Heinz? Yeah, I might actually change this in line 181. So I changed the dash to a plus sign to make it for the map entries clear Yeah I'm a little so the So here's the thing that I that I'm struggling with with that annotation The so the CE is the CE prefix was meant to be basically just a namespacing Where you everything is pretty prefix with CE you can go and take the string that follows CE And basically stash that back into a dictionary and then and then clients will go and consume The attributes from the dictionary and the CE will be stripped. So that's just a purely just a wire construct The injection now of this this dash or plus as an indicator Now turns that into a far more elaborate string operation because first you need to go and break the string apart And then on the other side, you need to go and reassemble it again And that is assuming I guess That a there's a case where we actually have properties which differ only by by name by case And then you can also need to go and find out the casing Without any help just from that arriving HGP header so Again, I'm leaving towards towards that that sounds all very complicated and basically speaks for us our Camel casing assumption from the base spec to be probably not correct Because it's causing complication here Okay, uh matt I see your hand raised Yeah, I just wanted to Did you got me my brain cells firing? I thought I Acknowledged that I think that this discussion is indicative of the maturity the spec and the the Current state of where people are at with it in terms of implementation That which means that people are looking at what tool I'm going to use what product He got every last bit of performance how to avoid confusing implementations Um, and and if the next logical step then is to ask yourself Since this discussion is about you know, how do you do word separation? The question is why do we need word separation? Why you know, if you look at all the examples here above Why is why do we have to have an event in every name? It seems redundant by context unless you have multiple times or multiple IDs You need to be the differentiator, you know word differentiator or some other indicator But unless it's it's needed why wouldn't you compact the event format and and the keys as much as possible? So I'll just throw that out there Okay, thank you Um, so I have my hand raised. I just wanted to point out one thing I had I put this as a comment in one of the other issues out there If you scroll up in the chat, you can see where I put in seed as my property I just don't want to feel to remember that HB headers can have in essence multiple values in there So you put a semicolon and then put you know name equals the real proper name in the proper casing with dashes or whatever you want and that could be Completely independent from however it's specified on the left hand side of the colon as HB header So we do have options like that as well. I'm not necessarily advocating that I just want to make sure people remember that we had that kind of option so Going forward though. I hear at least two options here um I suspect people want to want to think about both of them going forward What I would like to suggest in terms of a next step here is maybe clemens. Could you open up a pull request? of With your approach of just lower casing everything so people could actually look at your pull requests side by side with um Christoph's and they can take a look at that and maybe on next week's call We could figure out which direction the group prefers. Does that sound okay? Yes What other people think in terms of next step? Is that an appropriate next step? Or is there some other approach you guys like to take to this? Okay, obviously if someone has a brilliant idea for a third alternative don't hesitate to open up another pull request Because I I think having them in their complete form as full-blown spec edits makes it really easier for people to compare and contrast them going forward So don't don't hesitate to create another one if you need to Yeah Um, all right can raise one point This also like I said, it limits it to alphan americ characters and it means you cannot use utf 8 or like Like tim said like turkish names will be possible So I would just like to go out. Is that cool with everybody or do you think this is a no go? Because that would also change with the direction of things Now, I think I think we should we should really go and constrain constrain the character set to be Stay within ascii Because you know everything out. So you have the choices of either allowing everything gets in utf 8 or is constraining it to ask you it seems to be the the two fair choices And I think that's something that we can reasonably do and should do Any other comments on that? You know in 2018 handling utf 8 isn't rocket science. I mean neither approach is completely insane All right anything else All right, any other comments or questions on this topic in general before we move on to the next agenda item utf 8 would be nice I don't know the hassle it implies with the sdk and the transport specs, but it would be nice especially as Not having to encode the payload it anyway if it contains any Let's say exotic uta utf characters Okay, any other last comments questions All right, so I think we have a direction to go All right now since we've Approved the pr about the bar for extension attributes We have this one here called sequence Uh, let me hide the comment here for a sec This one's actually been out there for quite a while. I don't think it's actually changed much recently Um, let me pick on somebody. So I'm not doing all the talking here Christoph would you like to talk to this one? Or did you have the do you enable to? I can try okay um Yeah, this didn't Thought out uh from me, but I think like from uh, we as commerce tools the company I work for This is like one thing we generally have that people are really so we are working in the commerce space And it's for a lot of things important to understand the order of events and that you make sure that you process them in the right order um Yeah, so what I did is Ben started it. I think and then I added some stuff to it What is what is what is basically does is Two things it generally says there is an attribute called sequence And there is some value in it and we don't really know what it is but uh, if you know how to interpret it then You can find out which event comes from another and um, the second thing it does is it defines a sequence type And if that is known to you then you know how to interpret what you find in sequence And this we have one sequence type defined called integer and it's basically an increasing integer So pretty straightforward starts with one then goes to two three fours and so on Um, and then it wraps around at some point Yep, all right. That's it. Thank you. Thank you. Are there any questions on this? Now keep in mind this is just an extension. So the bar is lower They have to be perfect. It can change over time The question here for the group is whether this Uh Seems appropriate, you know a thing for us to add is an extension. Is it in scope for our spec? Um, does it seem like it's at least well thought out not necessarily saying you agree with it or that you're gonna implement it But does it seem like it's a valid thing that people may want to do as an extension? I think it is and and part of that is because I believe somewhere in the spec we specifically call out being able to process stuff kind of in an order And that's not built into the the basics back. Um, so I think this is a The very least applicable for an extension if not A full-on property because I can't remember exactly where it is, but it's called out as a like a use case somewhere in the spec Being able to process stuff in order Okay, thank you any other comments, I see some people in the chat saying that they think it's a valid thing Let me so let me turn the question slightly around Is there anybody who would object to adding this as an extension? I I guess I I think I was common. I was considering commenting on this one. I I like the concept um, I think we could do with a second example and I guess I was more hung up on the um, the fact that it was For an integer sort of a gapless sequence So I I was sort of thinking there was an argument for You know saying it's of type gapless sequence rather than integer or um Just a gap sequence and I'm more sort of coming at that from the fact that as soon as you say this is a A gapless sequence. It means your publishers become stateful. Yeah, so um That could that could result in problems in some situations But that was more of a I think a semantic argument than anything else Okay, it sounds like also the kind of thing that might be worthy Of a follow on pr mainly because I think it may require a little bit of back and forth to get the wording and the and the syntax of it quite, you know a little bit More fleshed out Right, and so I think you maybe have a follow on pr might be more appropriate and keep in mind These are just extensions. They can change anytime. They're not going to be version with the rest of the specs So these things are free to be changed on a daily basis if they need to be so okay Okay, um, oh There was a question about uh, should it go into the main body? And I think that the sequencing is is specific to Context, um, we already have time for ordering across boundaries So I think it looks good in the extension. I'd vote for it to be there In favor of adopting it. Okay I'm matt, um Thank you matt All right, so back to the question. Is there any objection then to adding this? I'm not necessarily Okay, let me I'm sorry. I'm going to rephrase this Um, I'm going to get exactly as a two-part question here. Um, is there any objection to this? being a an extension property This is hind I'm not sure if it's a strong objection, but I think we're adding redundant data Where generally the transport protocols already have sequence numbers And there's a large complexity where this all only works if there's one producer of the event Because now if I have let's say five producers to the event going to the same namespace Which other transport could be a topic or a queue The ordering is only for that stream. So you would not have order across all of those And those are usually solved at a transport level as opposed to in the Message itself at least as far as something that would relate to the event Okay, um matt, I think you have your hand up. Are you responding to that comment? yeah, I This is the same project earlier and I hesitated because I didn't want to Put you off agenda but you know We're going to see a lot of these things coming up where people have want to add a value And it always comes in a pair. You have to give it a type So you always have a type value So, you know one thing that we we did in past approaches is we went to a tagging methodology We have just an area where you just put tags the tags themselves you use A uri and uri by means of having a protocol and domain Well, mainly the protocol it indicates the class And the value itself can be appended to the path or other other ur means at the end as a As a value or a query string or whatever So if you if you might want to think about if you you're going to have a lot of these things come up having a single line way of doing it instead of having to all cases have pairs or sometimes tuples all right So I apologize. I forgot who was making the other comment gem. That was you, right? I did make a comment. Yeah, okay Um You but you were the one making the comment that you weren't you weren't herperson sure if it was an objection But you were the one that would raised it, right? I believe so. Yeah. Okay. Okay. So um How how strongly do you do that way because? I'm not taking chair out of half here. This is strictly me. This is one of my representatives in the group I tend to have a fairly low bar for extensions because the whole point of them is to see whether they're useful or not um And in some cases it may be duplicate information and that's part of the thing that's going to get fleshed out when people play with it And if so people may decide, okay, we're going to kill the extension But I know that there are necessarily not to say i'm sorry not necessarily all protocols Have some sort of ordering aspect to them That that this would fit nicely into Um, so that's why my my bar is fairly low for what should be an extension I look at this as more of a playpen type area and that's why I I'm very resistant to to Having a high bar as my take on it anyway Anyway, uh, jesse, I think your hands up So, you know that you you've kind of gone in that direction. I would that's what I was going to say earlier is I I feel like it's an extension so I'd be inclined to allow Something that isn't explicitly um airtight, but this this sort of thing Um around kind of a sequential protocol does open up a few Things that I wonder about One I believe it was matt that brought it up where or actually matt replied to someone who brought it up It might have been gem Just recently brought up the idea of you know multiple producers So multiple producers multiple consumers have possibly something where the sequence matters from the beginning to an end And there's a number of steps So that's that's not really something that's Informed here and also I think this sort of opens a It opens a door to advising in the case of you know, what happens if if you receive things out of order And a sequent, you know one one or more members of the sequence are missing And what's you know, sort of that's that's obviously something that is to find outside the scope of the spec in this extension But I think calling that out Sort of goes down the road a little bit So I think yeah, I mean I'm not I don't have any specific advice around this and I wouldn't Block the acceptance of this particular pr, but I think I just wanted to voice that that's sort of where my head starts going Okay So we could take an action item to extend this with some information about something like vector clocks To give an example of multi producer sequencing Yeah, and and I think that might actually shore up half of my concerns is to have an example and to end that That also indicates, you know, like you can find an answer It's not as it won't necessarily be here, right? So gem not to pick on you, but I'll pick on you Since you're the one that voiced the possibility of a concern about this um How strongly do you do you feel about this? Is this something that you'd like to Have the group like take a formal vote on or you know, how'd you like to proceed? Yeah, I mean I I I agree with your comment around this being a relatively sort of low bar thing And it to me it's sort of an an end-to-end application concern not a transport concern. Yeah um, I I think The other comment that was made around multiple producers um, maybe that could be addressed by saying that sequences are Uh within a type and a source or something like that because I would assume You know, you would generally have one event Source, you know given one publisher per source. So maybe that is a clarifying point, but other than that, you know, I Um, it was just an opinion. I'm not uh dead set on anything Okay, so there were a couple of comments made about potential changes Or follow-on pieces of work that could happen here Of those ones that were mentioned um Are any of those things that people feel strongly enough that they'd want to block The current pr from going in as opposed to doing it in follow-on prs Because I'm trying to figure out whether we should move forward with in essence doing a vote now or Does anybody feel strongly that their suggestion should go in before we even adopt this one? Okay, let me phrase it more succinctly Of the suggestions mentioned is anybody advocating merging their suggestion in before we merge this pr Okay, not hearing any I'm going to take that as people are okay with doing follow-on pro request in that case Is there any other question or comment about this pr before I ask the question about adopting it? All right. Is there any ejecting then to adopting this pro request and merging it? All right. Thank you guys. That was cool I Feel this process will get a little easier as we start adding more and more um, all right next issue this one I'm not sure we only resolved this today because people may need more time to look at it But the open messaging spec or protocol I transport where we call it Has been out there now Excuse me. Um, hold on a minute Let me get to there was some questions about whether this spec met the minimum bar So without talking For the moment about the content of the spec itself I was wondering if people had had a chance to look at this particular comment, which I think was edited Last night About why they think it meets the minimum bar and I'll give you guys a minute just to read this in case you haven't read it yet Okay, so I'm not necessarily going to ask everybody to definitively say for sure whether they think is met the bar or not because I think they may need more time to To think about it. However, I am going to ask the question of is does somebody have an initial reaction? And I or a gut feeling as to whether this specification based upon the information this comment is going to meet the minimum bar That depends that depends on what's actually so if there has been a change to the uh, uh submission Because my understanding is that open messaging is three things It's an abstraction And then it also has a wire format and then it's a benchmarking a collaboration project And I think the only thing that really matters to us here since we're talking about intro would be a specific a wire Specification and the last time I looked at this submissions. I haven't looked haven't looked uh in the last few weeks um was um that it didn't describe a wire spec But rather referred to more like a framework Okay, it's the the the spec as it as it exists is very abstract Okay, but do you have a comment on like because one of our minimum bars was things like adoption in the industry and stuff like that Do you have an opinion clements on whether these satisfy the criteria? so rock so I mean if you look at open message and everybody needs to need to really look at this themselves But if you look at at it from a yeah, so those are projects that exist in multiparty Organizations so that clears that bar But I would say if you look at the contributors list for both projects for rocket mq as well as for um open messaging You'll find that The community is rather unilateral in both Excepted open messaging in the benchmarking project where there's a lot of activity, but that's not related to this submission um, I would I would so personally um I would not be a big fan of um of this binding, but if it's a wire specification then I'm probably cool with it Okay, is there anybody else on the call? Excuse me who'd like to comment on their feelings about whether it meets the minimum bar not I poked around the open messaging cloud website just now a bit and I can't find anything that looks like a wire Format I can find a java api, but it just talks abstractly about headers and fields So it's hard to understand what Doing this would mean concretely Uh, is there more pull request somewhere that explains what you'd actually do? Okay, I'm not sure. I think that's I think that's getting to what clements was saying too. It's very abstract Yeah, the spec the spec is really abstract and really what it is about is that this it's the it's The rocket mq wire format which is interestingly so the rocket mq wire format apparently That's my understanding of it has been elevated into the open messaging specification without the actual wire specification making it yet on the open messaging side Which is The thing that kind of rubs me in the wrong way and it's a little weird is it's it's apache rocket mq something has been put into apache By alibaba apparently Open messaging has been started by alibaba and most of the people who I see contributing to the project Basically exclusively except in the benchmark benchmarking project are from alibaba Um, so That makes me a little uneasy about this because that's all smells Like preparatory work being done being done under the umbrella of an organization without much, you know community pull Okay, we have some hands up. Uh gem. I think you're first The when I looked at open messaging a while ago and I haven't looked I have to say for quite a while My understanding was more of a programming model So that would to me that's akin to somebody wanting to do um A mapping document from cloud events to jms it was more of a That sort of level I I never took it as a wire level thing. I took it as a abstraction of a messaging infrastructure Okay, I think Vlad you were next and then Heinz so Vlad Yeah, this is a tiny nitpick, but in the comment There are no Links to the claims. I again, this is a nitpick, but if Doug if you could move to the comment, they're saying that the several companies the voice support of I'm gonna use I would really really like to see links for this and this is not just for this PR But for most PRs who Claim such stuff. I'm not saying I don't believe the comment But I'm seeing their links for open messaging apache rocket and q and apache bulls are but no links for claims That companies would support or they're getting involved or have another participation If we're if we have a bar that bar should at least come with some proof not just claiming they have participated They definitely If they announce their participation, they definitely have a blog post or a tweet or something. That's official and that should be a link Can I get you to make that comment into the PR itself? Sure. Thank you very much And Heinz you're next Uh, yeah, just a quick comment where we actually had somebody in our group do a evaluation on Open messaging and the concern was we could not use it for asynchronous type Messaging which you would probably consider a lot of events would be asynchronous and not necessarily synchronous so what they've been looking at as an alternative which You might want to have a look at to compare if this should meet the minimum bar Is the information on the async api that is out there as well Which is what our people tend to be leaning towards for asynchronous eventing as opposed to They could not seem to make it work with the open api Okay, Perry. I think you're next Yeah, I was just looking at their github repo seems to have a tab under specification Or it's a little bit spread out that you can get in to see what they're expecting in message headers And there's some descriptions about types expectations. So it is a bit more prescriptive. Um, I think it's it's less uh flexible It was like there's concerns that seem to be outside of the messaging space to me And there is information there if people want to reference that Okay, so all the points everybody's I think the speaker key is empty now. So um All the points you guys brought up seem like very valid things Can I ask all you guys who spoke up to please add comments to the pull request itself? In particular if you needed additional information like lad us for pointers and stuff like that Please put those as comments into the pull request so that the author can respond to those And then please take a look at the pr itself in particular the the actual file changes themselves to see whether that Whether it meets your guys needs whether you need more information whether it's too abstract, you know Whatever comments you feel appropriate Because this pr has actually been out there for quite a while and they've been kind of blocked by that That bar that we defined and so I feel kind of bad that it's taken this long for us to give them a definitive answer so if possible I'd like to On next week's call come back with a definite yes or no to them and not string them along any further So please put your comments out there sooner rather than later. So they have a chance to respond to them And with that I think Pretty much out of time, but there's one thing that I forgot to do that if I need to go back and do On the previous pr about the sequence attribute Now I know Kristoff since it's basically Isn't he'll write the pr and I know he's expressed interest in supporting it I'm sorry. He's claiming he's one of the voters who says yes I want to you know I want this thing in there because we have a minimum bar of two voting voting entities approving extensions Who would like to be the second voting entity approving that extension? Anybody want to volunteer for that if you're voting in a company? You can put me down for that and who's that? Thank you I was going to pick on Vlad since he expressed interest before but I'm glad someone else spoke up voluntarily. Thank you All right, cool. With that, I believe at the end of the agenda or at least for the time for today Um, are there any last-minute questions or comments before I go back and do final roll call? All right, not hearing any let's go back up here. I think I heard most people Matt, I heard Uh, Rohit. Are you there? Yeah, yeah. Okay, cool. Um Oh, you're there twice. All right, uh, red auto Renato, are you there? Did we lose them? Yeah. Oh, yeah. Okay. Excellent. Thank you All right. Is there anybody on the agenda who I did not get? All right, who's on the call is not an agenda All right, and that is Vladimir from Vladimir Bakvansky from PayPal. Uh, I have joined. Uh, this is my first time with the group Excellent. Do me a favor. Can you put your full name and uh, you said you're from PayPal, right? Yes, that's right Okay, can you do it? Yeah, put your full name into the agenda thing into the agenda doc and I'll add you to the attendees I appreciate that. Thank you You're welcome All right, anybody else? All right, in that case since we have a whole two minutes last chance any other topic we want to Want us to bring that really really quick All right, in that case, we're done. Thank you guys very much. You made it through quite a few today I appreciate that. I think you're done. All right. Talk to you guys next week. Thank you. Bye


Hi everybody, my name is Paesong and I'm not sure how many of you are coming here for domain driven design. Actually, I just start the title without thinking about it. So I'm not an expert. But after I read a few articles about domain driven design, I think there's something we can share. Even we do not apply domain driven design, we are actually using it every day. So we can think about how we can learn from it and apply some of the concepts to our project. First about myself, I have been developing software for more than 10 years, like server site for 10 plus years, I was three years and one year for web development. Right now I'm doing my own project, it's called REST Studio. Later I can give you an introduction of that. So even we do not know what exactly is domain driven design, we can figure out from the name that it's about maintain model and data integrity. Because in a way, when we talk about software, we are talking about input and output, right? Everything is data. So we can take a look at Wikipedia definition of the DDD. DDD is an approach to software development for complex needs by connecting the implementation to an involving model. Here involving model means the model could be changed, there's a time. And while here it's for complex needs, I will talk about this later. Here's some basic concept of DDD, when we are talking about context, of course everyone knows we have context even for our programming languages. So it's the setting in which a word or statement appears to determine its meaning. For example, when we are talking about client object, it means different in billing system and authentication system. In authentication you just give the username and password, but if it's in a billing system you have to provide the address as well and something else. So if a developer from a billing team talking to a developer from authentication team, they can get confused because they are working on different contexts. Next is domain, of course everyone knows domain means different areas of this project, what it is in the real world, for example it's a financial domain or HR domain. Next model, a system of abstraction that describes selective aspects of a domain and can be used to solve problems related to that domain. But for us developers, model means schema actually, but for the domain expert it means the real world object. So for simplicity, when we talk about model today, I'm talking about schema. Next is ubiquitous language, language structured around the domain model and used by all team members to connect all the activities of the team with the software, actually I think everyone knows UML or internal development team you can use like Protobuf. It's also language actually, we use JSON as well, XML as well, as well as everyone in the team understand the language. Here's an example of context, we have payment system, we have merchant service and accounting service, in each context we could find the same name, the object with the same name but they actually mean different. The next thing is TDD, building blocks, it's not a full list of the building blocks, I only write down four of them, the first is entity, entity means it has an ID, you can get the entity by its ID, identify, the value object, for example you have a user, the user can be fetched by user ID, but value object does not have ID, like you have a geolocation, you have latitude, you have longitude, but it does not have an ID and you do not care about the ID as well, you never fetch a location by ID, it's usually nested into an entity. The repository, actually I do not fully understand repository yet, so from what I understand it's a collection of the same entity. If you program in Java Spring data, you will find out there is a layer called repository, it all works with the same entity. So next is aggregate, aggregate means an object that can contain different types of entity and value object. So on the right side you can see in our development world, we have database, we have data access object or we can use it as a repository, we have service layer and controller, usually the aggregate happens on service or controller level, I believe most of you already have done this. So here's an example, we have an order delivery which contains a user address and the ordered items, here the order delivery is an aggregate, the order items address, we do not care about the ID, it's just a simple value object and a user, we can fetch the user from the user repository or user service whatever to get the user by user ID, so the user is an entity. This terminology, I believe it can be used for developers communication, even usually we do not. So a few more words about the model, between domain expert and system designer, the mission is to describe how model works in real world accurately, but among system designers and developers when we talk about model and the mission is how to implement a robot system that keeps data integrity, when we talk about model we talk about data integrity. So for DDD implementation it's usually, it's not usually, you always start with model the domain first, then you start to design, architect your API or your SDK whatever, then you start to development refactoring, it's about implementation, then you have your model, you have your functions, now you do the unit testing and the integration test, when you're done this with different subsystems you have to do continuous integration as well, once it passes the integration you can package your tested domain into a model to deploy for other references, at this stage you do whatever other implementations, there is new requirements coming, you have to start to redesign your model again, so it always starts with model, the model must be tested and provided for the other subsystems to use, this is how it works usually, however back to the first slide that DDD is for complex needs, because it's very expensive, it's not for everyone, if you want to keep DDD clean you have to isolate a lot of domains or a lot of models, so Microsoft is not recommending DDD for everyone, only for complex needs, so do we still need DDD, of course actually from what I just talked about, DDD have very useful leading concept for us like data integrity on the workflow, I believe actually we are following it already, so when we are developing our REST API, which is HTTP based, if you use a JSON, you will know JSON does not have a schema naturally, so if you want to keep your model and data integrity, how do you validate your JSON data, so why do we need a JSON schema, because we need reliable JSON, and we need universal description language for JSON validation, without language dependent, like you have a library for Java, only an annotation based or whatever, we do not need that, we need something that can, not every developer can understand, so JSON schema is developed to validate JSON input, and itself is a JSON object, here's an example, what this structure tells us, so the schema says we have a JSON title user, it is an object, it's not a string, it's not a number, and in this object we need username and user ID, any one of them is missing, it's invalid, we reject it, it has three properties, so the username is a string, the minimum length is six, for the user ID it's an integer, but notice here it's not, here last line is an integer, and the format is, of course you can see it's a big int, so with this schema we can validate data, so left side is the schema, and on the other side you can see because the username is not, there are only three characters it's not valid, here for the last line it's not an integer, and the format is not correct, so it's not valid, for this one even it's missing the last line because it's not declared as required, it's valid, so now if you haven't done this before, on the server side when you receive the JSON data, you know with this schema defined, you can validate it, furthermore when we have a schema, we can describe our data more accurate, more easily, like on the left side you do not have a schema and model, you describe your user as like users, every object in this list should have the three properties, but on the other side you can see because we have modeling our data, we know we have a user which is exactly has this schema, so we can see for this API we have a list of users, and this user point to this model, so what we should do with the validation, DDD always emphasis on the data integrity, so on the client side you actually should always validate the request and response, even you will think about its option or there is a performance issue, but you should do it because data is the most important thing, on the server side actually you must do it, even you do not want to do it, because it's very dangerous to assume the request data confirms to require schema, and if the dangerous data comes in it can be passed into database directly without knowing, I'm saying I'm not seeing in one system when you have more systems, you have more databases, you just don't know which one will break, and the data if they pass from one system to another system you cannot fix it at all, so it's too risky, so you must validate the request data, even with the validation we have other validation rules like the conditional logic, like if the user is admin then you have to contain something, some properties, if it's a user has been rejected like suspended, you must contain something, but for this schema cannot help you, the only thing you can do is to consider, split your design, split on conditional schema, split into multiple APIs, like for admin you have a schema, and for other type of users you have other APIs, this is just a suggestion, I don't think it can apply to all the APIs, okay, so we were talking about microservice and how we can use it with DDD, what is microservice? A microservice appears of application functionality factored out into its own code database, speaking to other microservices over a standard protocol, so here microservices logically has its own code base, team database, there is no way one microservice access database of the other teams, you can only talk to them by interface or by API call, the standard protocol could be JSON, could be HTTP, could be IPC, could be anything you want, as long as it works, here's an example, like I downloaded from the website, so you have the mobile app, you have browser, here you have the API gateway, you have a website, the two consumers consume API from the microservices, split it into its own database and code base, actually this can be more complicated because the service itself can call API from each other, this is a simple one, yeah, and you can see the advantage here, so what's the problems? With microservices, not like before you have one big code base, if you change an object, actually you can detect it immediately, if you use something like Java, of course not JavaScript, if you use Java the compiler will tell you, the model has been changed, your API is not working anymore, but here you split into different modules, so if the other module changes the model, you have no idea it has changed, the data comes in as an old version of the data, now you cannot decentralize into the object, the system is broke, I copy this picture from another speech, so you can see we have different systems, A, B, C, D, E, F, if E is not functional, it blocks model integrity or C and F, you can see the messages from E to A is actually broken, but A didn't do anything without it, with it, on the bottom the AC means anti-corruption, on the bottom for some of systems it implements the anti-corruption layer, which converts from one format to its own format, if you implement this, this is actually a pattern, it can help you solve some of the problems, but you can see, you understand what that means, here are a few strategies we can use, first is shared kernel, when we talk about a client in accounting service, oh sorry, think about another service like building service, they have something shared like the username, user ID, if you want to separate the object completely, that means you have to save the duplicated data in different database, it can work sometimes, but in most cases we'd like to have an upper stream model, so when you create the sub-model, you have to validate against the upper stream model first, you have to always confirm to the upper stream model, then you can extend the object or use other method to extend, to implement your own logic, this is one design strategy, another is what I just mentioned, for each sub-system you create an anti-corruption layer, add an adapter, accept objects that confirm to upstream schema, but convert into its own format, why do you do this, because it's very easy to do the unit test, so with the data samples, if anyone changes the data schema, they have to provide testable data samples for unit tests, so you use the data to test against your own format or your own adapter, you will find out the problem immediately, now why continuous integration is important, because you don't know when, you don't know how a sub-system suddenly gives you the wrong data format, so for each change, please run the continuous integration, so next is, we have talked about so much about the schema, so we have mod APIs, we have mod systems, now it comes to how I can find the schemas, how do I know which schema I should test against, how do I know which system has changed, I think most of the developers prefer code first, they always code first, then there is something wrong, come back, we code again, but I think it's not the best way to do it, you actually should come out with your spec first, why, because you have the spec, you have the interface, everyone knows you have these changes, they will validate your spec first, and they can fit back immediately, this enable fast iteration, so you will, like I have a friend working in a company, his colleague is in USA, he works here, every time he finds something wrong with their API, it takes two or three days just for one run, so we need fast integration for microservice, especially for microservices, and when we have the spec, it's a two-way agreement, which means the producer and the consumer both know this change has happened, we both agree, this is the spec, this is the API we should follow, my job is to follow the spec, not calling you or email you every day, one strategy to do this is to provide the mocking data, because actually when you're mocking data, when your mocking data is well designed, they actually cannot tell it's real data or it's a mocking data, right, so when you mock the request response data to validate the data structure, you can avoid possible errors, also for the clients, the API consumers, they actually can find out the problem easily, because they usually prefer to apply the data into the UI, sometimes you have to look at the UI to find out a photo is missing or something is missing, yeah, to do this, after you're mocking this, you have to come out with spec, which is actually the schema and the document, then both the consumer and the producer agree with it, we can start to code, because now we know if my code works with the spec, it's not my problem anymore, yeah, the spec becomes the standard to evaluate a client's, a client developer's responsibility, it's a both, it's a two way agreement, okay, so for the rest API, we have the open API, how many of you have heard about the swagger, I think many already heard about that, it's also called open API itself, it's actually a JSON schema itself, so beyond the model, you create model, you also can create the API with the same JSON schema, here's an example, I'm using the YAML format because the screen is too small, so on the left side you can see when you describe an endpoint, the URL is patch, the method is get, it produces application JSON, the response status code should be 200, the result is a list of paths, the schema should be a array of paths, the paths is defined still using the JSON schema as I just described, so here, we wrap up, everything is about maintain data and model integrity, validate your input and output, all this, and spec first, try to come out with your mocking data and make it work first, and consider open spec, open API spec for rest API, I think that's about it for the speech, any questions? So when you design the whole system, I think it's not easy to define the complex boundary, so you see how many services in your system, so as your example, the counting, so for example, in your system, you have locking, you have to pay business, many business, so when you design the whole system, how can you design the different domain, how do you design, how many services in your system? That's a very general question, I think actually we have to look into the requirements first, because you are talking about different systems, different type of vendors or clients, so you have to- Yes, it can be very complicated. It's very hard to answer this without looking at it, but I think for example, there are different patterns for that, like factory, if you are talking about the create object, because you have different types of objects, you're considering different objects, they have something in common, so you want to design your database for performance or whatever, you should centralize your model creator, like make it its own service, it's called a factory pattern, but I'm not sure I can answer the rest of your questions right now. Let me pick that up, so the funny thing about the main dream design is that you need to become a domain expert, so you design a new system for directly, not the illegal one, you probably spent a few hundred dollars making a pharmacist drunk to interview them, what are they doing and then you will learn okay, there are the vendors and then there's delivery and then there's verification with the doctor and so by learning about the business, you will learn what are the objects in the real world and that become your object boundaries, of course when you push it further, then a lot of these objects you initially found will actually be facades to smaller areas, but the only way to get domain group design right is become a domain expert, so you create an application where artists can share performance events, you hang out with an artist, otherwise you don't understand what's important and that's the whole idea, it's like that we move out of the domain, we are so cozy with like tables and rows and objects and all that and deal with the real life, I recommend the artist one, that's good fun. Any other questions? Okay, so I was talking about the spec mocking for a reason because I'm going to introduce a product of mine, it takes a few minutes, so right now our workflow is like always code first, then we have to deploy for the consumers to consume, then we have to finish the document, then the consumer feedback, if there's some problem we back to code, deploy, document feedback, it's like a cycle, it could take like days to start a project, however the problem is we thought our design was a good idea, but we spent days or weeks and the prototype it turns out is not working, so if only we can prove the idea faster, so what if we can speed up the API development so that the server developer and the client developer can work together at the same time, they start at the same time, we do not have to wait for the API to start, so what REST studio does is actually it enables you to design, deploy and document REST API seamlessly in a few minutes without coding, so you only design, you do not code, so like what I said, you design the spec, you make sure it works, then you start to work to code, so REST studio contains a few modules, modeling tools, document tools, request executor, you can think about postman and there is a smart mock server, it takes like one minute to start your project, one minute to create your input, one minute to update your mock request and response and that's it, and by the end of the five minutes you have a live mock server, you have swagger compatible documentation and you have a powerful API explorer, wait, I'm not sure this works or not, okay, it's recent, like we want to create a blog API, it's Jason, so request accept and response is Jason, we assume that our code will run in our localhost, then it's created, now you want to create your endpoint first, there is a CRUD creator, you provide the path, the id name and also the object name, it enables you to create your API image with one click, so now I want to bring up the server, here you can enable the cloud sync, oh okay, with this cloud sync is enabled, everyone can access it with the id, then you have your mock server to create the environment, the environment is should be set as default environment, you can see you have a global variables, now back to the, you can run it already, it's online, it's live, but it's too slow, but it's not found because you haven't pushed your mock data yet, you haven't defined it, so you want to define your mock data, here is data, like when we create a blog, it should have a status, success, we all agree with that, right, then we should return and list the blog id, right, you can generate the schema, both you can label it as required, you upload mocking responses, back to your executor, it's live, you can access from your mobile, whatever, with this base URL and this, now you want to construct your request data, like title, the first blog, content, hello, word, you can save, oh sorry, first save first, then you have the data, remember what I said, next step is schema, so you'll go to schema editor, extract data from the request, generate its schema, label it as required, you upload it, now remember the content is required, if I delete it, I run it, the mock server actually tells you you're missing properties, so the mock server can detect your errors, of course if you do not want to do it on the server side, you can validate it on the client side as well, with this and you can also preview your request if there is something wrong, to demo a bit more about this, I make it back first, make sure it works, yes, so now I want to say the title must be, the minimum length is like 32, you upload your mocking responses, now you'll go and try again, it tells you it's too short, fails to validate that, yeah, so, oh I forgot, you also can simulate different types of status code, like if you do not want 200, you want 201, you create a 201, like created, true, but as you can see the default is 200, you can trigger the 201 in the query, oh, I'm not sure it's enough or not, okay, so this is 201 and created as true, and if you disable this parameter, it returns the default response, that's why I call it smart, although it's not smart enough for me, right, now we have an API explorer, a live mock server, you have the document here, this is what your API consumer will see, they have the attacks, all the required types, descriptions, examples, actually this is a swagger compatible, so later on it's still under development, so you can export as a swagger project, you use that, you can generate your server and client-side SDK, and also there are a lot of open source tools for swagger, that means you can edit here and you can do whatever swagger can do as well, yeah, so last I will demo the cloud scene, right now it's I copy this value then go to, we assume this is another user, stuff, oh I haven't published yet, sorry, I have to publish, the design follows that you have to commit with change log, so everyone knows what you have changed, you have to do that, it's not a sync automatically without knowing what has been changed, it's here, so for API consumers they can change and do whatever their request will be evaluated on the server side, why so slow, okay, it works, this is what they see, the last one I want to demo the import swagger, this one is actually from the swagger editor, they have different examples, so you can see, I'm not sure you have used it or not, but the network is too slow so I'm not going to load it, this is the definition of a swagger project, it's very long, okay, see, it's here, you can actually execute it, so that's it, so what it does, it enables you to start your project and finish your prototype and validate your request response very quickly without coding, the spec is here, you can do whatever based on the spec, that's for this one, right now it's in alpha stage and it's going to be beta in like two or three weeks, right now we still have a few breaking changes, I'm going, yeah, that's it for today, I'm going to publish this URL later in the Slack group, yeah, so everyone can try it out, let me know, yes, I hope it can start up, hopefully, yes, you have questions? Do write operations and view operations use the same definition or the separate write models, for example, when you create a new block example, the actual block model has a timestamp, but when you create a new model, you might just specify a subset of the actual model, exactly, that's what I call conditional skew, right, so you have the same object, but actually they are conditional, if this is like, yeah, yeah, right, so you have to decide which way to go, you can use the same one, but the required one could be wrong, and some logic is conditional, it is correct in this condition but it's not correct on the other condition, so if you want to make an unconditional schema, you have to separate them, and you have to separate the API as well, yes, that's how it works, okay, thank you.