AsyncAPI Community, 17 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: AsyncAPI SIG meeting 55 (August 17, 2021)

Description

This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #55.

https://github.com/asyncapi/community/issues/51

Chat:

00:15:12 Michael Staub: This is like javascript Object.assign() which makes sense to me. Does it do a deep merge though? If the message had ‘Cat’ in the array would the final array also contain ‘Cat’?
00:16:34 Sergio Moya: Wouldn’t make sense to raise an error on tooling whenever a property is found in both places
00:16:34 Michael Staub: That answers my question.
00:16:58 Michael Staub: Or warning at least
00:19:33 Michael Staub: Here is a similar API: https://www.npmjs.com/package/deepmerge#options
00:20:13 Simon Heimler: Here is the PR: https://github.com/asyncapi/spec/pull/532
00:24:19 Sergio Moya: You can/should remove the all the `required` except chirp on the trait
00:26:50 Michael Staub: I think it makes sense as is, just needs to be better documented.
00:27:17 Michael Staub: I can’t think of a use-case where merging arrays would not be an code smell in the API?
00:42:41 Michael Staub: Perhaps the Object could have an ‘overrides’ field that specifies which traits ( or other sources ) that should be overridden?
00:42:50 Simon Heimler: https://jsfiddle.net/FannonF/yLsonr57/latest/
00:42:53 Michael Staub: So force the users to be explicit
00:44:41 Fran Mendez: I’m not sure I get it Michael. Mind expanding?
00:45:06 Michael Staub: Sure
00:49:32 Jonas Lagoni: That or create a trait object instead of relying only on JSON Schema for defining traits
00:52:25 Michael Staub: So create a DSL and ditch JSON?
00:53:05 Sergio Moya: HCL!
00:54:16 Hugo Guerrero: DSL for everyone! :)
00:55:02 Hugo Guerrero: That way we can secure our work for many many years
00:55:09 Sergio Moya: lol
00:55:14 Michael Staub: Decades*
00:55:20 Fran Mendez: Forever haha
00:55:30 Fran Mendez: XSD FTW
00:56:47 Michael Staub: If they coexist, then it will not be a breaking change, correct?
00:56:55 Simon Heimler: yes, I think so
00:57:02 Jonas Lagoni: Yep
01:00:39 Sergio Moya: Are u talking about FCL? FRAN CUSTOM LANGUAGE
01:00:55 Fran Mendez: You mean Extremeño?
01:01:36 Aayush Sahu: XD
01:01:37 Lukasz Gornicki: https://github.com/asyncapi/community/discussions
01:02:25 Simon Heimler: Ok, I'm not sure on the Breaking Change nature on a second thought. If you introduce a new feature that users start using and the tooling / consumers of the spec don't support it already it will break.
01:02:48 Michael Staub: thanks

A

uh Thank you bot, um so welcome everyone. It's asking api public meeting um if you're on the meeting at the meeting on the meeting in the meeting for the first time, it's recorded it's going to be published to uh youtube. um So just keep that in mind. We cannot change that for transparency reasons with the community.

A

um We have um a few folks that are new to the meeting not to the community, but um um some of them are admitting for the first time. So we always have this moment where, before jumping into agenda, if you want um you can introduce yourself to the um to other participants in the meeting. um You can also already drop a question if you have, uh if you don't want to wait until the end of the meeting with your questions, you can ask them beforehand.

A

So now that's the best moment to do it.

B

Okay, should I go ahead here? Yes, all right, so my name is simon. I'm from germany. I do work at sap and I um I had my first experience with async api one and a half years ago, so we used it for some purposes and yeah. So the reason why I joined today is because I noticed some behaviors and I raised an issue and a pull request, and this is already on their channel. So we can talk about that later, yeah. So any questions from your side.

B

Anything people usually tell in the introduction.

A

So far, so good thanks for introducing yourself and but, as you said like in your case, uh your topic is already on the agenda, so you're covered.

A

Anyone else before we start.

A

Okay cool, um so there are two topics: uh one is an update of progress from my site on the idea of hackathon and conference for us in dpi, and also the other topic is um yeah, something that simon already introduced like the trades topic um and also the proposal that um simon had around the uh around trades. um The proposal is already opened, but there were some questions from the community.

A

um Don't remember the names, but basically the question. There were some questions like that people need some uh some more explanation and yeah. Simon came up with um idea and found some time to be here on the call and introduce the topic, and I suggest we skip conference topic at the end of the meeting, because we don't know how much um the trades discussion will will require, and anyway, whatever we do in the topic of um the hackathon and conference, it's all anyway asynchronous it's all. There are some links that I can just share.

A

If we don't have time for for discussion for that, um so uh simon, do you want me to give you a co-host right? So you can share screen yeah.

B

That would be helpful thanks.

A

Okay, now you're a co-host, so you should be able to show your screen all right. Can you see it now? At least I can see it and uh yeah. The stage is yours. So let's continue.

B

Okay, yeah thanks, so this issue was actually raised by a colleague of mine.

B

It was that he discovered when, when we applied it at sap that the trade behavior wasn't working as we anticipated, it would work and therefore some examples were raised here. So I think my colleague did a good job on describing how you can reproduce this and what he expected and what actually happened and to show you this. I would like to start by going to the playground with an example and then also maybe ask you what you would expect from that.

B

So if that's okay for you, so all right, so we have an animals api um and there we have a bird channel, and this bird channel contains some messages, and this is a really typical inheritance example. So you have a bird and a bird is basically using a trait that it's also an animal and therefore you want to reuse some properties of animals to not define it oil again for birds.

B

So, for example, we have this animal trait, which is basically an abstract animal, there's, not just an animal. We always have concrete instances of it, and animals have names and they have a type and because the type isn't defined. Yet it could be word or dog in this example, and only the bird itself will take this property and overwrite it and state. Yes, I'm a bird and I can also trap which the animal itself can't.

B

So what is now the expected outcome if we apply the animal trait to the bird and yeah, the problem is, as you can already see it in the playground that the bird has now inherited all so. Everything in the trait has overwritten what we already defined in the bird. So, for example, the type of the bird is not bird, it's bird or dog, and the description of the bird has even been overwritten with it's an abstract animal, and I think that illustrates the the problem we've seen with the trade behavior.

B

So it yeah, I would say it, it doesn't work like trade inheritance in other languages or what you would expect from a trade and that actually limits our use. The usefulness of this feature for us, so we think trade inheritance would be really good to have. It would help us with our use cases, but the way trade inheritance works right now is not working for us and might even cause cause misunderstandings.

B

So any questions around that example. So did I get everyone on board here.

B

Or does someone uh disagree or what would you have expected here.

C

um So um I may clarify: why is it working like this? So your example is uh illustrating inheritance right. That's why it doesn't get it right. That's why it is reversed, so trades it is coming from ramel, so it was inherited from rammel, and so the purpose of traits was more like compared to karami languages techniques, it's more about composition than inheritance right. So the idea is that you have bare minimum of your message and you start adding stuff.

C

That's why whatever is on the trade is overwriting whatever you have on your message, so it is so the technique behind the the traits, its compositions, not inheritance,.

B

Right, okay, I see yeah, but if it's composition there shouldn't be any overwriting at all, because then right.

C

I think so yeah in many programming languages, when you use composition, it really replaces what was there before right.

B

Okay, I see okay, that that helps understanding.

C

What it is so, for instance, I think uh what was the name in python of this at whatever can't remember um anyway. um So this this is um used for composition, usually that you apply on classes or in function. I think classes you can add at whatever on top of the class and it will modify your class by adding or removing, usually adding a thing I think, adding or replacing methods from your class or properties of your class. So it is so the the the recent.

C

uh So that was the the ideal, let's say, ideally the reason for for for trades right. So you come up. So in your case it will be like your message will be um the bare minimum right and then you use a birth trait or a dog trait. You know what I mean so the birth trait will contain the description, a bird and uh and chirp through or volume or or string.

C

Sorry, um and then the dog trait will have, uh I don't know bark as balding and a different description, and but your base message doesn't even have a description at all right. So.

D

C

So you, you could actually do the same thing, but the reverse and the concepts you know more in a competition fashion than than the inheritance fashion doesn't make sense.

B

Yeah yeah, that makes sense. Okay,.

B

Yeah yeah, then, and maybe was thrown off, because the spec states that we use the json merge patch behavior, which is clearly about merging objects and complex structures. And if you just have traits like that, you wouldn't even need to do that.

C

Yeah but you you have to merge, I mean you have to uh override.

B

This yeah yeah.

C

Actually, yeah I mean we were like uh for nested objects. You might want to merge right or you might want to replace completely. That's why, for instance, in the case of arrays, we only uh we completely replace the array. Yeah.

B

C

Is it is not possible to merge your race because of this I mean there are limitations on this language, so I'm just in uh this emerge patch, like you, have to choose if you want to replace a race or or or merge them or or what the the risk of merging two arrays, for instance, is that you end up with duplicate keys, which might become something invalid.

B

Yeah yeah right so so that's.

C

Also something I.

B

Identified so I agree with you here: yeah.

C

So I hope that explains um why it is this way. I think, um if you want just for illustration purposes, can you can you share this document with me and um I'll try to.

D

I'll try to.

C

Reverse this, so so I I can illustrate what I'm talking about just for those who are not getting it right now. It can be tricky sometimes to talk about these things.

B

Yeah yeah right, so I've added it as a issue. Okay, so sorry, so, okay, okay, then it would be interesting to see how it works in ramel and um it's actually interesting, because I also use trade inherit yeah yeah. Basically, the name says that um I guess trade is interpreted differently, depending on which project or frameworks you're using.

B

So, for example, composition could also be working without any overwriting at all, just by.

D

B

There right and you would never get into the situation of merging and I've also seen frameworks where you do use traits and you do have inheritance like object orientation, but with multiple parents. Things like that, so yeah.

C

Actually yeah, the thing is that there we have to make decisions here, like whatever, whatever whatever it is.

C

Like uh I mean, maybe we can end up ideating a way to support all these possible combinations, like I don't know like I want to do a merging or completely replacing or support, merging, arrays or not or but to keep it simple, because it's usually um like a so traits are like sugar, syntax, syntax, sugar, synthetic sugar, yeah super synthetic uh saying, syntax sugar uh over async api, somehow right inside, um so they are not really needed to create anything they're helpful, but not really needed.

C

So that's why we didn't want to complicate so much and uh on that and it's like okay, so that will be enough hope. It helps someone right and uh but let me just uh work on this other okay, I'm reversing the example. So I can illustrate what I'm talking about and uh so I'll share my screen right now, maybe lucas you have to give me cost permissions. I already gave it to you you're fast.

C

So yeah sure, okay, but let me just I guess it's too boring to see my friends writing somewhere in the board.

C

C

Just take all of this.

C

So headers blah blah blah bird message word message description. This will be a word. This will be.

B

But I think I I got.

C

Yeah, it is more it's not so much for you, but for people who might be watching the recording later. So that's why I wanted to make it clear right uh so or for people in the call now who are not just maybe not getting it but not raising their hands, so so yeah um so yeah. So that will be it's yes.

C

So yes, so the idea here is that you have a message, birth message that uses the word message trait right and your and your headers are just you know like. um Actually this one is not needed at all.

B

Yes, you can right.

C

That's it, so you will make sure that your headers are described here right. So you use it. The word message which describe uh defines this headers description of earth properties, name, type and chirp required all these three types can be paired, you see, so we did. We did this. We accomplished the same thing but uh reversing the the approach.

C

B

Except that now we have moved everything and we wouldn't have needed trades at all. So in order to make the trade useful, we would at least have to introduce an animal message yeah. So.

C

The thing the thing so to make it to make it more compelling I will say, is you probably have to do it more granular right so actually like with composition right, so it is um bird chirp, maybe and um yeah, something like like yeah, let's just focus, I'm sure.

C

So I can just come here and say something like this.

C

Oh I hate this sorry for the.

C

uh For the f word yeah, oh no, this is, I don't even know how to write this api.

C

Okay, worksheet doesn't exist, that's right.

C

Yes, so description, it's there, it's a bird blah blah blah, okay and then what do we do is.

C

It might fail, I don't know, I never tried to bear with me so yeah. That would be it. I don't know, let's check yeah so now, yeah.

D

C

Gotta be more granular right, so it's like uh a bird message contains this birth chair uh message, trade, which will include the functionality of chirp right. um Actually, no wait it's here, so actually how it works.

C

Yes, so yeah, so it is not defined here. There's nothing about sorry, there's nothing about shirt here, but um it is defined here on the verge, which is message straight right.

B

The required property will now behave interesting because you cannot ever override it again so having the required property in the trade act was actually one of the things that caused troubles for us.

C

Yeah, so this is a this is problematic. Yes, you either define it here or you define it here in both cases you'll here you will have to be aware of this of this trait and if you forget to make it required, then it's going to be problematic. So if we we can have it here and remove it from you.

B

But that was our guidance basically that we shouldn't have anything in that trade which would get overwritten anyway at any time, but that's changed over time.

C

Yeah, so that's the problem with um with uh with trades, basically right now, because you have to choose if you want to merge a race or not and we've chosen not to as in decent schema patch to be compliant with digital schema patch. Sorry, just in patch.

B

Yeah, actually, I think it's good that we don't merge a race. I think the problem for us was the order of the inheritance taking place. What of the merging yeah.

C

Yeah yeah so yeah, I'm not saying that this is perfect. It is not, as you can see, it is not readable for all use cases, so I think the proposals can make sense and maybe I don't know like it would be great to see if, by converting trades to inheritance, we are actually breaking other use cases and uh and uh and make sure that we're not. um It will probably switch your use case, but probably it will stop serving other use cases right.

C

So so yeah honestly, I don't know how to I don't have a proposal for this. Like I don't. I think this. This is one of those situations where someone has to lose right or someone has to be um in disadvantage. My opinion- maybe not maybe there's something I don't. uh I don't. I didn't realize yet.

B

Yeah, I can can showcase the the proposal um that I created, but um actually I see your point and it's also one option uh that is defined here so that we, it might be a good idea to not change the trade behavior like it is as of now, but then it would be good to describe how it works and how to use it safely or correctly, and what to expect here, yeah. So.

C

Maybe maybe if that helps, maybe it's probably going to to add more complexity, but uh I was thinking that maybe we could provide another mechanism that will be based on inheritance and uh just so it's just so. The wind don't mess things up between inheritance and position right.

D

Now it will be like.

C

It will be like one or the other- you either use traits or the new mechanism for inheritance, uh but not both, because otherwise this will become a chaos. So I don't know just ideas just throwing ideas. Maybe it's a bad idea, because it will uh increase the complexity of the spec.

C

I don't know, um let's we need to check the drawbacks as well and uh and my my um so you show some in the easter use of some examples of um how it doesn't fit the current definition of traits and uh and even an example of how it will fit these inheritance uh examples.

C

But I challenge you to do the opposite, like you're, to challenge your proposal and see if it breaks other use cases which are not inheritance related so like trying to abstract away from what you've seen in the past and it's like. Okay, let's come up with an use case uh that people might have and uh and see. If my proposal adapts accordingly or not because we can't easily be biased.

B

So yeah, I can think it's true, but I think it doesn't because I used this kind of multi inheritance in another project already and there I used it sometimes for composition and sometimes for classical inheritance, and it did both, and the only thing you need to do is to switch the order of how it's applied, but it will break the current spec behavior. So this is technically a breaking change and therefore I'm I'm well very very that this is a problematic proposal here, so that it has a lot of things to think through properly.

C

Yeah, so don't worry about that, because I think we are approaching a breaking a major version, so so we're approaching agency free- I don't know when but yeah just with the public subscribe thing. uh This is going to be.

C

um This is going to be a breaking chain, so it can be included in this same version and then we include all the breaking changes at once and create chaos.

E

A

E

Having something and then being able to either extend or override it, um it might be worth having a look at the overlays stuff. That's happening in open api, it's a little bit more like overriding individual fields, but if there's something happening there that we could build on, then it would be nice to kind of keep them as pr expected or predictable um as unsurprising as possible.

C

Yeah, so actually overlays was also taken from grammar. This is the concept of overlays and uh there's an issue open, I think, for implementing overlays and using kpi, and um but I think it's totally different, because overlays are meant for, like overlaying two different documents right in this case, it's about in the same document. You have references so like, like. I would say like that when you overlay two documents, you the the reference of which documents to overlay, um it's external, it's external to the document, while with trades the reference is internal. It's like like.

C

I want this to implement these traits right, um so it's I will select the opposite of overlay. I think they are complementary, overlays and traits.

B

That's interesting. I haven't heard of that at all.

F

I think to a second: what simon was saying is it would be nice to have really clear examples of what each of these areas are, because, as part of the overlay discussion- and I would say, the extension discussions within the oai uh there's a lot of confusion about, what's which, when something would work in one, and I think there needs to be- maybe a playground to go, hey, bring your ideas and hey. That's a that's a trait, that's an extension, that's an overlay and and then it would help people see and what's happening in which.

B

Case uh so you really get it.

A

B

A

Because you raise the hand.

D

Yeah I use this nice feature of rising hands.

D

um Nobody knows I discovered right now, so I mentioned it like a few minutes ago on the chat, so we are seeing different ways of implementing this that yeah the overlays I didn't know about it and I was looking at it, and someone also suggested to to merge trades on trades and overlays on open api. There is an issue opening there so perhaps because fran was saying that was completely different. Perhaps there are more people that think that they can coexist, but anyway.

D

um The point is that, as that's a short short uh change that we could do there, so I suggested we could at least give tooling the right behavior for uh whenever we parse a document, and we discover builds that are duplicated in both in the trade and the main uh message to drop an error or a warning or something because at lorna should they say that there's like tons of surprises there yeah you don't know what you're gonna have there.

D

You can more or less think what what it is. Thanks to the editor, if you're using it online, you can see the documentation, but otherwise it's like.

B

Good luck, right, yeah! That was really our problem because let's say you have this trade and you have required and now you add another message that uses a trade that did work in another case and you don't have the straight in mind. You will never realize that you're accidentally overwriting, something you you didn't intend to um yeah.

C

Yeah, just two just to reply to sophia's uh proposal about the warnings or errors uh we're following the jc merch patch uh rfc here so um and the reason we're doing this is to comply to a specific standard right so to not reinvent the wheel over and over, um even though it's not perfect, because then, if we start like this is like json merch patch, but not really, then you know, then, when we're going to implement the parsers in other languages, people will not be able to leverage existing tooling for json merch patch.

C

They will have to do their own one for our for the trades. So that's the disadvantage that you will have to implement this logic yourself on the fire service.

C

The I mean it is to some degree it is an excuse, uh and it is a valid point, what I'm saying, but to some degree it isn't because it's like yeah uh for a user. It would be like for an amazing gpa user. It's like I don't care, that's not my problem I want to.

C

I want to be clear and again you're pointing me to a tooling vendor or a tooling developer problem, not my problem right, another problem of the user so um solve it right, that's what that's what the user might think right, so so yeah! uh We just need to keep a balance, of course, um but um but yeah. I just just wanted to mention that this is the reason like we try to be compliant to specific standard right. So.

B

C

Reinvent the wheel about the same thing.

B

Yeah yeah, I understand that so I did try to implement this on my own, so you can do it with just a few lines of code, but I totally get your point.

C

Which, like I said it is, it might be a valid point to some degree, but on the other hand- and I tend to be on the user side of things in this case- is not a valid point at all, because this is the same thing as, with the same discussion, the same questions that I've been getting over and over people say like hey: why don't you merge open api and snk api into a single spec, or instance of the document or into uh single, tooling or- um and we were like?

C

No, it's gonna, add complexity to tooling, which is true but yeah, but the user will is like, and I mean I understand, but it's not my problem again.

B

Better move the effort to the tooling than to the user, yeah yeah.

C

So it's like you're translating problems of the tooling or the people asked working on the spec to the user, yeah moving, translating the problems to them, and I mean sometimes it's needed, because we cannot be handling everything we need to be smart to when we choose which battles we want to fight, but because we can't fight everybody but yeah. The user might probably think that uh yeah not my problem. I want to do this and this is a pain so yeah, I'm.

F

C

I'm saying like I'm, I'm I'm trying to justify, not just if I like, illustrate or or raise awareness of why it is like it is, I'm still not happy with how it is, and I think we should keep uh moving forward with the proposal. Maybe adjusting it a little bit. I don't know and making sure that or maybe as it is, but before we proceed as it is right now the the proposal that you made um to make sure that we're not actually breaking anyone else, yeah.

B

Yeah, that's understandable and the.

C

Understanding of trades, not the documents, the documents can be migrated, but their understanding of traits, because probably nobody is complaining right now, because for them it was cool. It was perfect, but if we change it then a lot.

D

C

Will appear and say: hey this doesn't make sense at all right, so yeah, um let's not say which of them. Yes, we should. We should be doing it properly right and making sure that we don't leave anyone inside.

B

Okay yeah, then I would just show you uh the proposal itself and then we can later decide what to do with it. So I see your points friend and maybe we need to consider adding it under a different name then or yeah. Let's see okay, so the actual proposal is rather simple. It's.

A

Just before you jump into proposal, simon.

B

A

Thing that I have to understand, um because it might be relevant for the proposal. uh You mentioned a few minutes back, that you experimented a bit, and you said that um you tried the composition, inheritance and in most cases or majority of cases, it was enough to change the order yeah. What did you mean by order like order of uh applying trades uh in the parser, or what exactly do you mean by changing the order or.

B

Exactly yeah, so it's just a matter of um so you can even keep the merge patch algorithm. The only thing you need to change is that you apply the target object with the highest priority. So basically you keep all the merging order, so the traits are overwriting each other down the line, with the exception that the target object is has the is basically the last in the line and also overwriting what the traits are merged together or if you start with the target object and then every trait overrides the target object.

B

So it's just a matter of changing the position of the target object from being the least important to the most important. That's the only change.

A

Okay, that's nice! Thank you.

B

Yeah and then you can still use a composition, but in that case um you, then you can use it for um then you can't overwrite anything with a trade. So that's a use case. That would then not work.

A

Okay, thanks, you can go ahead with the proposal.

B

Okay, no, that already was the proposal, so uh basically it's the changing the uh so either we we keep the algorithm because of the reason friend mentioned. So it's already established it's already known. We have tools and libraries around it. We just change the order and then we get something that works like inheritance, but can also work for composition with the drawback that you can't override.

B

But this drawback that you can't override is actually something which is a bit weird when we are using the chasing merge patch, because the whole spec of json merge patch is about overwriting.

B

And therefore the other option would be to create a generic, deep, merge, algorithm and not reference to a spec and just define how merging should take place, and it's actually not not that complicated. But I see that it's a drawback so in this code example here I will put in the link here.

B

You could basically say it's just two or three rules, so objects will be merged. Recursively, I would say null is something we can skip, because it only makes sense for merge patch, and then we could say everything is overwritten, including arrays, and then it's a really simple algorithm.

B

So basically, I would even propose to simplify it like that.

C

So you mean even the race will be merged.

B

No, no overwritten eraser.

C

Or still be overwritten.

B

Yeah, because of that I I have some experience with that. That causes a lot of troubles, yeah.

C

B

C

Yeah, especially like this schema can break like just schema. Definitions can break if it defines the same item on the rate-wise that can be um yeah can be problematic.

B

But uh in with this behavior we wouldn't have that much problems with the required array, because I can always override it and then at the end, after applying all my inheritance, I might already know what is required and not, and then I can define it at the latest point in time and it will not get overwritten again.

B

But after your explanations, I underst didn't know much better why you chose the merge patch than before meeting.

B

Okay, yeah right, so that's already it from my side. So.

C

So mine, you might explain you were saying like if we reverse it um reverse the order right. uh You can still do um like composition right.

C

Yes, I I'm trying to imagine how this will work, but I can't.

B

Yeah so when, when I was doing composition, I was always thinking and this will get an own object, that is the composite, and this is merged in and there's.

B

If you do composition, you will never run into a merging situation because, like in a programming language, you just add in another whole object or class into your existing class and there's no merging problem at all. Yeah.

C

Yeah, it's completely replacing yeah.

A

I I see michael raise the hand, can you do anything.

G

Yeah I was making a comment. uh This is a great discussion by the way is an important one um in the chat which is these seem to be indirect conflicts. These two use cases right whether you want to do the merge or you want to use the inheritance, and so what I've seen done in the past other contexts is, you have default behavior right, but that can be overridden if needed, and so maybe um the example that was originally shown.

G

um If you don't explicitly have an a custom field called overrides or something in the message, the type property will be overwritten by the trades. That's the default behavior in accordance with the json patch. However, if async api then offered like in a you know a back door or a way to say no, no, I really know what I'm doing. I want this specific field or set of fields to not be overwritten by any traits.

G

Then you can also satisfy the inheritance use case, but unless you have some sort of back door in the action as a top level um field, I don't really see how you can support both of these use cases with one default behavior. But maybe I'm misunderstanding something.

B

Yeah so friend mentioned something interesting, you could basically, we could keep the trade behavior and we could have an um extent behavior, and then we have a message.

B

Sent and then you can choose either to use the extent or the trade behavior.

G

Yeah that gives you the most control, but it's also the most cumbersome. So I think keeping the default behavior as it is, does make sense to me, but again maybe I'm biased. I would expect the bird and dog array to override, um but this is a valid use case right. I think this is the synthesis.

D

G

So we need to support it like was mentioned earlier, like they don't care the users don't care they just want to. They just want to be as expressive as as they can, and so I think you know we should just discuss in the short term. We can talk about.

G

You know just updating the docs, making it clear with the default behavior but long term. This seems like a valid use case that we should uh support somehow.

C

D

My only one suggestion.

C

Yeah, the only downside that I see that I see of like picking which uh fields might get overwritten and which don't is that this part of, like type, object, description properties. This is not a simple api, so this is json schema.

C

We don't control the spec, so um so it might have to be done using extensions which is like you know, x, dash whatever, and then it comes. It becomes a custom behavior that you know not the not the core spec behavior right, but something that an extension that something might or might not support.

G

Yeah, that's a good point. It's a pretty serious trade-off in terms of adoptability.

B

It just comes to my mind, there's one other thing that I noticed when implementing a validator for this, so we also need to define the order of when the dereferencing takes place. So I think we had some discussions and I looked at the playground how it was implemented, but it also makes a difference to the inheritance behavior if you resolve dollar references before or after making the inheritance, but I think after thinking through it, it's quite obvious that you de-reference first, but this is something we probably should define as well.

C

Yeah, like like the referencing, is right now like a fussy uh land right now on the spec, because we are allowing people to use volarev, even in places where it shouldn't be allowed, because that, because the parser is using a tool like get some ref parser, I think on this one.

B

Yeah, you start on this one yeah.

C

Yeah and uh and it's just taking all the dollar reps and the referencing, and then once we have the whole document, then we validate it exactly.

C

So that's why you can use dollar ref when, where, where you shouldn't be able, uh because we validate after they have been the references so yeah, it looks like that will also be defined at some point like where, where you can use the ref and where you can't and the order of the referencing and, like you said like, if we're gonna the reference before applying traits or after applying trades right so.

C

I agree with that, and I just want to throw something here that I've been like chatting about with jonas the other day and uh and more and more people, and it's like maybe the whole situation that we're facing right now like we want to do this or that and it's becoming like quite complex already, the the amount of use cases that we have to support, maybe the whole. The whole problem comes from uh the language itself, right like being piano or lemon-based language.

C

So yes, but yeah like this is just like for anyone who wants to think about it. I don't want to start another conversation about it now, but uh yeah like uh I I was just just for for uh for reference. I've been playing with idea myself of how it will how an async api document could look like with something like graphql, syntax or typescript, syntax or somewhere.

D

C

Not typescript, but your typescript types, I mean not the whole language, you know or graphql syntax, something like that. um Yeah and uh yeah some yeah exactly michael, so something like a detail and that could probably then be transformed to json behind the scenes.

C

But um but the user will not have to deal with this complex, complex case instructors and instead they will deal with uh simple, simple dsl, but again just wanted to mention it. But uh that's another discussion and it might not ever happen at all so yeah.

B

Yes, now that you mentioned it, so I I totally can understand your point, because uh yeah yaml itself is a beast already and you have already inheritance and yam yeah right. So some point in time. You have to choose if you leave a problem to preprocessors or two generators and keep the complexity out of the spec itself,.

B

Okay, that's yeah.

B

Would that work here, so you can an amp.

B

Yeah, I I don't have it right out of the box.

C

B

You know what I mean, so you can you.

C

B

Can't you can't use.

C

These um features so though it's it is explicitly stated on the spec like you can only use the subset of the same maps: okay, okay, because in the end, what you're, using yaml but we're, transforming everything together.

B

Yeah that makes sense that simplifies it.

C

I love when, when I mentioned a something geeky like a new dsl or something like that, and then it's like everyone is like: let's go ahead like let's change everything, let's break the whole thing.

B

Yeah but this will break a whole ecosystem of tools and parsers and json schema validation, code, intelli, intelligence.

C

We probably wouldn't be able to use this schema itself so and yeah so yeah.

A

You went off the proposal quite a bit, um so what so? You'll you're gonna update the uh the proposal with the with the use cases right: okay,.

B

Sorry, lucas can you repeat again: yeah.

A

Just to like just to summarize the discussion so um because, like during the meeting, we're only discussing we're not not making any any decisions, obviously yeah, especially this, because the recording has to be shown to others so like the outcome from today is that you basically will provide some more examples right on the proposal or or you will think through. If you even want to go forward with it,.

B

Yeah, so I think I already have the examples in here uh and a code example how how to change it, but.

B

What's new to me is so the understanding of that we might want to actually keep the overwriting behavior and then maybe we should think about how those if they could coexist or how they complement each other and what the basically the drawback of this proposal is compared to the override. So what use cases would we break like fran mentioned?

B

I? I can add that.

C

Also, well, look lucas, maybe you want to, or maybe we can. I don't know like uh try to ping the community um as much as possible uh for those, especially for those who are using trades heavily and and see if it will break their use case. Maybe it doesn't so and maybe they're having the same problems as simon was having and and then it makes sense, just change it and that's it.

A

And that's what we already did. That's why we have this call, because, uh after triggering community, some voices came up in the proposal.

A

So um I I just I suggest, like I mean simon you're, the you're the champion for the proposal. So it's up to you um how to proceed so, just after the call think about the proposal, what we discussed and update us on the pr take time, because I can assure you that holidays is not the best uh moment to engage.

D

Your community.

A

uh Like we have a great article from uh from jesse that we could publish on nothing api and I'm just blocking him to not do it because we're going to lose the opportunity to get good audience, because I can see on google analytics everything's, like everyone is out on holidays, like everyone literally so take your time because, like even even that, we tried hard to engage with the community and some people jumped in. I think that much more people will jump in in september so just um take time to rethink it.

A

um What you want to do.

B

Yeah thanks: I will do that and that's not something. I think that we should hurry.

A

I mean the release, schedule is september and then it's january and even like for september. It's already, uh I would say too late, because you have to provide implementation as well. So I mean I'm not deciding here but just like um being like objective like it's. It would be super hard looking on the loads that we have and for now it's just me and from accepting changes so yeah. It's uh just take it into consideration like, but as you're already aligned with us, like you're, not in the brushes for us.

B

Yes, exactly the only thing I would consider is to collect issues that ask for a major breaking change in the spec because um yeah when thinking about it. Technically, it's not a breaking change to add a new behavior, but for the tooling it is a breaking change, because if the tooling doesn't support the new behavior, it will not work for what users intended with the spec.

A

Yeah, at the end, it depends how we do it if we change the behavior or just add something with the new version. Parsers we'll have to follow up.

B

Okay, but you don't plan to release a 3.0 release in september.

C

Surprise and the dsl as well the new dsl.

C

That would be amazing.

A

I'm already predicting that, like in the future september release window, it's always going to be like super minor things like some binding new binding or something some something that is not very complicated because I mean like we have to respect community and like nothing, not engaged like. We even had one uh one person engaging with with us um and pushing the bindings on holidays, so we we definitely have to while being on holiday. So we definitely have to make sure we uh we respect community and don't force too much big decisions in this time.

A

Okay, so one minute until the end conference and hackathon um quickly quickly um yeah for this quickly, by the way, not sure if in other countries you have it in poland, you have this law that when there's a commercial of medicine um at the end of the commercial in radio, somebody has to read the side effects and, like those people, reading these side effects they're like masterpiece like the speed they do it. I'm not gonna able to do the same update about conference.

A

So, just from my site link uh to discussion in community um repo, where we have a few topics that we discuss about the conference, it's for sure gonna happen in november uh hackathon october, um and the new thing is that is not yet mentioned. It's there by me.

A

I have to put some updates is that we I had had some discussions with the linux foundation, because I think api is now based uh part of linux foundation, some some of the tooling we can get from them for free, some of them paid, but yeah, that's what we will have sponsorship for and it's gonna make our lives easier. But let's then continue asynchronously in the discussion step.

A

Thanks a lot to all of you for joining, um especially to you, simon, for preparing the uh the discussion and explaining everything. Well, thanks a lot.

B

Yeah, thanks for inviting.

A

And um yeah it's end of the day, at least for europe.

A

See you in two weeks in the ipad friendly time zone.

C

Around here bye-bye, thank you, bye-bye.