AsyncAPI Community, 16 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: AsyncAPI SIG meeting 44 (March 16, 2021)

Description

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

Agenda & Notes: https://github.com/asyncapi/community/issues/15

Chat:
00:09:15 Fran Méndez: https://www.asyncapi.com/slack-invite
00:11:58 Maciej Urbańczyk: https://github.com/asyncapi/spec/issues/507 JSOn Schema support
00:13:55 Fran Méndez: https://github.com/asyncapi/spec/pull/511
00:14:16 Fran Méndez: Stages for spec contribution that we’re going to apply from now on.
00:16:53 Lukasz Gornicki: Message Id in the spec https://github.com/asyncapi/spec/issues/458
00:22:16 Sergio Moya: 👶
00:26:54 Fran Méndez: https://github.com/asyncapi/spec/issues/390
00:49:42 Lukasz Gornicki: https://github.com/asyncapi/spec/issues/513
00:50:06 Lukasz Gornicki: https://github.com/asyncapi/spec/pull/511
00:52:43 Lukasz Gornicki: https://www.asyncapi.com/blog/february-2021-at-asyncapi

A

Okay, recording started hello, it's a uh public meeting of asking api community, um it's tuesday.

A

I don't really know what day exactly, but it's tuesday it's morning and um where most of us are with coffee and we have a few new faces. At least me, I don't recall gerald. Did you join the meeting.

B

No it's my first meeting.

A

Okay, cool: do you want to introduce yourself to the group sure.

B

Sure um so my name is gerald. I work for mulesoft but in the training department. So I'm not I'm not involved in the async api engineering and product initiatives, but we have training and a code base that we use for some of our courses.

B

That is heavily based on message based integration and I started writing async api specs for that, um and so I discovered that there is no any point mq binding, which is the message broker we use, and so I I thought I'll start writing one um and that's why I'm here and I have a question on that already but I'll wait. My turn.

A

Okay, welcome and awesome that you just started playing with using api and you already want to contribute. So that's it well,.

B

You you don't get far without a binding. No, I thought.

B

I'm forced to contribute, but but I'm happy to do that and yes, okay.

A

C

It's worked well because dale is making the binding I need so.

C

You're, the lucky.

A

One- um and I think we uh at least also for me, um but I'm not good in names, so I apologize. If I don't recall you, but I think rakesh and pavan, I think um you're the first time on this meeting. If not, I apologize, um you have a chance. If you want um to say hello or introduce yourself you don't have to, but it's it's a right moment to do it.

D

Hey hi, this is rakesh. I'm practice head for integration department in a company called ruby conrad. We are working in a number of products like mulesoft solace. I have specifically been working with oracle, open api specification um and um yeah. We have just started with solace and we have been using async. We have not much used sync, but we have just started to so thought of like knowing more about it now. This is my first meeting here.

A

Okay, awesome welcome, I'm not sure if you know that we have also a slack channel. So uh if you want to also chat with us like after the meeting, because we meet every week every two weeks only then you can also talk to us on slack just yeah, if you don't know um so before we jump into the main meeting and one let's watch this thing.

A

Three two one: okay, um so the first item on agenda is question and answer, so I guess gerald you'd like to start with questions. Okay, yes,.

B

I I can um so um the the first problem I ran into now. I I I started. Writing that binding the the binding objects for for our message broker um and, of course I started writing async api documents that use those binding objects, and I want to ensure that they are syntactically, correct and I've seen there's a json schema for the async api spec itself. But the moment I enter my binding objects. That is invalid and I started writing. Json schema documents for my binding objects too, but they don't hang together.

B

So what can I do or is? Is there a path forward that you envision? For that.

A

uh So if it come, if I understood correct so you would like to write a json schema for the binding definition for for what's the name of the broker.

B

Sorry any point mq, but it doesn't really matter. No. None of the bindings have json schemata as far as I've seen yeah I'm. I'm writing a json schema, because just because it's nice to do that, but the binding object schema is not called from the async api json schema. So if I validate my json api document, there's no way for it to essentially loads the correct binding, and I don't know how to bridge that gap.

A

I mean so for for now we don't, I mean in the spec, there's nothing about um schemas for bindings. We don't have them, uh but we just recently mache magic. Did you manage to create this issue? You're, nothing yeah.

B

I created the issue in the spec.

A

Can you paste the link here in the chat? Yes, so.

B

I saw the issue here.

D

Oh okay, cool, so I just need to proceed.

A

With um with this, because I think everybody agree that it's a it should be super useful to uh to require that the binding has its own json schema, so we can validate it um or use it in the ui like like machine needs it.

A

um So we just need to proceed with pushing it into this pack.

B

Will that issue address not just the fact that there is there are schematic for the binding objects, but other also that the async api schema links to those schemata.

A

um So the issue like usually changes in the spec- it's it's just changes in the spec, but then um um the thing is just about supporting it in the in the parser. So it's all about the um like the official javascript parser. It just uses the async api json schema to validate asking api documents, but once we have bindings with json schemas, then the parsers should also get those schemas and validate bindings against against those individual schemas. Okay, I understood yeah. That would work, um but that's not part of this issue.

A

Let's say like first, we need to have it in the spec to later support it in the tooling true, but this can be already investigated. So another topic um after q, a we're just gonna quickly share the uh the proposal for how we will handle changes in the spec, um and one of these steps in like proposing changes is doing some proof of concept on existing tooling.

A

How a change in the spec would work with these tools. So I guess in case of this binding and schema for binding. um That would be a perfect use case for, for this flow like to to show the idea and show how it's going to work uh with the with the parser, but yeah later on. That proposal.

A

But yeah, but you did you also say that already, when you put a binding, um you get error that there's something invalid or did I miss it.

B

No, no, no! No! I! It was a conceptual problem I had I I didn't even try, but um I I did do both no writes, start writing, schemata and writing and using api document and then obviously there was no link to my schema. So I wanted to just discuss with you. What's.

A

Any other questions.

B

Will we go through road map or anything like that or what's immediately planned, or is that not part.

A

Of this meeting um we didn't plan, but if you have some questions regarding the roadmap then feel free to ask.

E

Yes, happy to reply as well: yeah.

B

Okay, I don't want to hijack the meeting. No, no.

A

Dude uh feel free to do it. I mean we don't have any anything super specific on the agenda I mean I have some updates uh that I would like to mention in the call some links, but um the first item on the agenda is also always q and q, and I because this meeting is for the community. So if you already have some specific questions then feel free to ask.

B

uh Yes, so so two more questions, one is very generic simply that um I'm working with 2.0 of the spec now- and I just want to be aware- if there's any changes imminent, that that will invalidate what I'm doing and the second question is: there are a few things um in the spec that that I would have thoughts are obvious no, but are not there.

B

So I I probably I missed something, and I wanted to see whether there's a plan to um to add those or whether whether it was constantly decided not to do that, and- and the most obvious to me is something like a message id. You know which every broker has, but I found correlation ids in this in the spec, but I didn't find a message with you. So I'm sure there is an argument for that. I just didn't see it.

B

Those are my two questions. Thank you.

E

So I think that, as per message id, I think there's an issue open. Maybe I think walid opened yeah, there's.

A

Already an issue from walid, so I can. I can.

E

And uh so that this this once will be making it probably in the next version we don't know yet, which version will it will be?

E

We don't know if it's gonna be three or if it's gonna be a new major version or if it's gonna be a minor version for sure, not a patch version, because patch versions only have you know fixes in grammar and typos and all this stuff right and minor things that doesn't change anything um and- um and I think messages is coming then, regarding if we're gonna ship, something that might invalidate what you're working on, um I will say so because there are, there are two things that will were, or I mean I would say so now I mean you can expect it to happen, um because there are two major things that we need to um solve before.

E

We continue developing more features and it's a public subscribe stuff that people get confused like we all get confused, even myself, sometimes like uh I'm getting it wrong. So we need to somehow solve this problem.

B

What do you mean the terminology or.

E

uh Some people get it the opposite. I.

B

Did the same, but it's very consistent now it's from the client's perspective, just like I get this from the client's perspective.

E

Exactly but if you're working with brokers in you know in uh private, let's say, imagine: micro, service architecture with a kafka broker or routing cube, rook or something like this, then it becomes weird um to look at it from this perspective and most people get it wrong, so um so yeah we need to make it less ever prone. I will say, unless um yeah, let's um or or or harder to get uh to get it to get it wrong, so so yeah.

E

This is something that we'll have to uh to solve, and I'm not saying that this is gonna become be a breaking change, but most likely will be um then there's also another one and it's reusing channels, channel definitions, so channel definitions right now. Can you now have channels the name of the channel and then inside? You have publish or subscribe right. If you want to reuse this whole channel definition in some other document, because yeah at least the publisher and the subscribers share the channel right. So you probably want to reuse this.

E

This definition, and um what happens is that you can't because there's this published or subscribed verb there and and it's like one will be published, but the other side will be subscribed, so you can't reuse it and that's a pity right yeah.

E

So so we probably will have to move things around and probably get the pumps and subscriber out of the channel definition and move it around somewhere, come up with some other solution or something so we can better reuse channels across facing kpi documents and and yeah, and that's mainly because people are um what I was saying right. If you have a public api, that's easy!

E

You just have one as in kpi file and then all your consumers will consume this same kpa file like in open api, but when you're in a distributed architecture- and uh you probably have one async api file for each of the services or each of the applications connected to the broker.

E

So you want to reuse this channel definitions right so yeah, the these are the ones that are on top of my mind right now, and that might be breaking things. Yeah, of course, as always, we'll provide migration tools. So if you, if you have, if you want to move from version two to version three and nothing has changed like we, don't we didn't remove anything or uh any feature or anything just move things around.

E

You usually have a script. I mean we'll provide the script for you to do it automatically with your documents. We already have one and we we will just immense, enhance this this one and yeah. So you you will not have to do it yourself manually.

B

And and what's the time frame you envision a month a year.

E

uh That's a good question: um there's I'm gonna, I'm gonna answer this in two parts. Okay, so first of all is um recently only recently dale started contributing to the spec more more often, and but the spec is really an area where almost nobody wants to contribute. So it was just probably my land until now and- and I didn't have time uh so- I have no idea, like uh you know like how far uh how fast this is. Gonna move the more contributors we have, the better.

E

Of course it's going to be easier and faster, but um now from my side like saying that from my side, um I'm gonna right now this week next week, I'm gonna start going into a parental leave. So so it means that for two or three months probably, I will not be doing much.

B

And your child is not a spec in this case.

F

Which is the spec in this game so so.

E

What happens is that I mean that's, I'm not saying that uh I'm not saying that um ice will be there to approve all the changes or anything not saying that, but I mean if more people like you and le and dale uh want to start contributing to the spec. I'm happy to. I don't know from time to time, show uh show up and and and read those changes and read this stuff and approve, and maybe not just myself like you guys, can can look at it.

E

So so we're so I don't become a blocker right and and and yeah so that that would be amazing, and then we become more people on the on the spec side. So so it's easier to to keep moving uh to be moving on right, so yeah. So in terms of timing, uh hard to say I'll, try to have proposals.

E

For or at least roman proposals, for um I don't know- let's say the next two months and then and then from there we can somebody can champion it and and continue it or or I or can wait and I'll do it after I come back from the parental leave, so so yeah hope it answers the question.

B

Yeah, no! No! No! So it it sounds like a few months, at least and um as far as contributing to the spec. That's a bit early for me! No, I'm not I'm not that brave, but.

E

Yeah, it's it's hard. I I I understand it's hard, that's why my last work this day has been on cleaning up the spec repository and the process. How what's the defining the process? How how do you contribute to the spec? What are the stages that you have to be following in order to get uh something merch into the spec, and um you know defining everything? Well, so so it's less dependent on on myself right so yeah.

E

So that's a call out. We need help with the spec, not just tooling,.

C

And with things like that, um I know that you don't like there's a lot of activity going on on all the different tools and the spec and the bindings and everything within this project. But is it helpful to raise some of those bigger issues, or maybe it's on us to put them on the agenda for one of these meetings? Is that useful.

E

I think that would be useful. Yes to put that you put it on the agenda for the meetings, um but um that's I mean that's great and because meetings are being recorded and and that's fine, but if you can also create issues you know or discussing issues that would be great just so people don't have to watch these meetings trying to scheme you know and find the right information right.

C

E

C

Level point of view, just because, like I don't know what we currently have um and I've only I'm new to some kpi, I've only tried to use it in um the use cases that you mentioned right where I was publishing and subscribing like.

D

C

Always confused like okay! Well, when I press this button, I'm going to send this payload and then the worker is going to pick it up or like now I'm doing kafka. It doesn't make any sense. Am I publishing or subscribing yes.

F

Exactly I'm publishing or subscribing.

C

I'm explaining how you communicate you can do you can talk and listen right. um So I'm very so I find that very confusing, and I think that was my first contact with the community. Like am I publishing or subscribing because I'm doing both and so stuff, like that, like I would love to have a high level of hey, there's an issue open or there's an example. We should look at and those kind of high profile things.

C

Maybe we should mention here as well as the you know, the slack channel chat and obviously the the way things are actually done on the github issues.

E

uh Just a sec, uh so I find the issue about.

E

There's an issue about the public subscribe perspective or meaning.

E

It's this one that michael from seoul has opened, but it's not um so much about the problem. I mean the title is not so much about the problem but about a specific solution. So so yeah.

E

Maybe it's worth to create another issue for discussion on what explaining what the problem actually is like. Why is it confusing and trying to understand? Why is it confusing for people and then once we clear there, then we can provide a a good solution right. I have.

E

I have some ideas on why this is happening, um but uh so I can. I can start this. If you want and then we can, we can discuss there better to discuss on the issue than on slack, because we have the free plan and slack and this will get lost so so yeah.

C

Even in the short term, I wonder if there's you know that reusable um the idea of being able to refer to you can probably unsubscribe these things and me also might maybe just ref out to a reusable piece. This current structure doesn't quite fit that, um but I feel like even that would be useful in the short term. I think it happens because what we're not? What isn't clear is we say? Oh, you can use async api with kafka, but you can't you can use lasik api with either a producer or a consumer.

C

You absolutely can't use it for kafka, and so it's very misleading.

E

Now you're right like um when, when people say like you, can use csn kpi with kafka or with robin mq or whatever, and they mentioned the broker um some, what some people, what they hear is that you can describe the broker itself.

E

You know it's like no is what you described is the application, publishing or subscribing to kafka or the rabbit and gear. um We actually had some some people asking like: why?

E

Don't we change the spec to document what happens in the broker itself instead of the application like like a menu of all the channels and and messages, and we remove, publish and subscribe, like you know like these- are the the this is the menu of channels and messages that you can get there and we don't know who's publishing or subscribing, but it's useful and I and I agree it's it's already useful because you at least for discovering channels and messages this is useful, but uh for generating applications, for instance code for applications or for generating documentation.

E

um Maybe that's not super useful right. It's like. uh Should I be subscribing to this topic or publishing like what do I do like so.

B

That way, you don't define an interface, you don't define a contract for an application. You define a contract for a broker.

E

Exactly and then, and and and there's even more, like you're, assuming there's a broker, which might not might not be the case like, for instance, if you have a browser connecting to a websocket server, there's no broker, or maybe the broker is a server. If you want, but then it's we entering this, you know we're land like where's the broker here, uh what is the broker uh and so so yeah? So what I? What I tend uh thinking about this publisher square perspective.

E

What I noticed that is that we we're trying to define too many different things like, for instance, broker-based architectures are usually private, usually and and they're distributed, of course, and then you have these ones like http to server servers and events or websockets, which are usually public and um and that's and that's no broker and there's a single connection. There's a single channel between them, a single line directly right. um What happens is that there? The connection is is point to point right on the on the on.

E

The websocket is client with the server and that's actually it makes sense in this case is to talk about client and server, because there's a client then there's a server, but when it's a distributor or broker-based architecture, there's no server or client anymore, at least not as in we used to think about them in client, server architecture or paradigms, sir. So there's a broker. There's a client, you can call the broker the server, but the server doesn't have any logic.

E

Logic is in another client. That's going to reply to you so yeah, it's a bit confusing, um and on top of that I think the confusion with publish and subscribe. It comes from uh visibility like if, if your stuff is private or if it's public, if it's something public like you're, starting with your consumers- and you don't know your consumers beforehand, then it makes sense to use this uh public subscribe like subscribe, means the same as a get.

E

Let's say in a rest, api right: you do it from the client perspective you're, offering your async api file to an unknown number of consumers, and then it makes sense to have the births from their perspective, so they can consume it. But when you're doing things on a private side, then it's like it suddenly becomes a little bit different on the private side and using brokers as well. It becomes a little bit different than um than this model right.

E

It's like everyone, everybody's who have every applications who have an asian kpi file, that's just one of them, and we can also not um assume that um there will be anything api file only with the file with the. How can how can I explain this? Like some people were suggesting that we uh so some applications on the messages they produce and and it's like?

E

Okay, so you don't define the messages in every async api file, but instead you point to the async pay file of the producer of this specific message, but again we're assuming that there's only one producer of or of a specific message. There might be multiple producers of the same kind of message.

E

So that's and that's a common case when you have like. I don't know, notifications, a notifications message. One service might be sending email notifications, another one will might be sending. um I don't know sms notifications, and there are. These are two different services or applications sending the same type of message. They only change the type attribute, uh type, sms type email, but it's the same kind of message. So so we have a problem there like uh there can be. It's not like one producer, multiple subscribers. It's multiple producers, multiple subscribers and and relationship right.

E

B

But that that can be solved now can't it. You just need to refer to one common schema document that has a well-known location, a url, essentially.

E

So that's what we usually uh propose: people that use track these things into a separate document, and uh and so you can reuse.

E

So you have the publisher, the subscriber and both point to common schema document right, which can be just a plain, json or yaml document that it doesn't have to be anything any special kind of document or anything and um and that I mean that works that works, but for for uh for reusing the messages right, but um but still the confusion about publishers scribes there because of the type of you know, the topology influences the way we think about it, I would say, and the privacy like the privacy, I mean the the visibility you know like.

E

If something is in our land or we're exposing this to the public and um yeah I mean I wish we didn't.

E

We didn't have this bias ourselves, but uh even myself I have this bias and uh and and- and I defined the meaning of publish and subscribe back in september 2019, uh it's highly confusing for me as well, but when I was trying the release candidate one of the spec, which was the reverse minion, it was highly confusing, sometimes for me, like it wasn't confusing when I was doing broker-based architectures, but it was highly confusing when I was doing public apis like websockets or servers and events. So it's like you, you it's it's a you.

E

Don't have a way to win here. It's a problem right. So with the current way of uh the current weight it's defined so yeah, I guess yeah. We need to solve this. I don't want to on the whole meeting with this public subscribe thing again.

B

So will we brainstorm on the issue that you will create, for that is that, where to put ideas, essentially.

E

That would be amazing, yeah yeah, yeah yeah. I can happily create it now like after the meeting I'll, create this issue, and I can link to different proposals.

E

There's this proposal from from michael from solas and in this same thread there's a stroman proposal that I did at some point and but yeah there's bruno bruno pedro is also hopefully working on it working on another proposal which will introduce the concept of role but um yeah, let's see so. There are many ways.

C

Also in the time that I've been confused about publishing subscribe, which is the whole time that I've been aware of seen kpi and in that time, open api has support for web hooks, so they are describing.

C

Just http requests, but in the sense that you, the ones that you send where you are the client right, because the open api spec, like you say, http, is quite simple as a client as a server you're, probably the client, um but it also describe it now also describes web hooks. So they have come and they their approach to that has been completely different um and I don't know if there's something there that might inspire us as well.

C

um It's actually two separate I'm thinking about this, though it's actually two separate uh sections, there's the paths section and the web hook section, and they both describe the data that goes in one direction and what you will get back as a result or what you will receive and should send back as a result.

C

But it uses the reusable path. Item request and to me this seems a lot like the reusable channel or message description that we already discussed. So I feel like there's some stuff going on there, that there's been changes in that spec, which might inspire what we could build on or avoid um in our in in async api.

E

You know the funniest thing here is that on version one of the spec um version 1.2 we had that separated like on different sections of the spec, like we just tried to unify everything under channels, and that was probably the the problem right.

E

What was what's causing the problem, but before it used to be topics which is the the channels now and uh can't recall now, but I think it was, I remember it- it wasn't uh publicly subscribed, but it was send receive verbs in another section and- um and there was this- there was a section for like public apis. If you want, you know like one of these sections was.

E

If your api is public, then don't use topics use this section here right, so maybe it makes sense, but maybe it makes sense that we split it back and we stop uh unifying things under channels and it's like if, if your api is public, if you're going to share this with your audience, then don't use channels use this instead,.

E

I don't know, let's see, this is something we have to for sure. It's not something that we're going to find a solution during the call we need this needs time to think about it and yeah a lot of time. Trust me.

C

Yeah, I know I'm the author of the web hooks addition to open api.

F

F

B

So I I think open api is too um one-sided. No, it's not. The the participants are clearly client and server, and I think that's the difference here, whereas in a message-driven system they're all equals potentially.

C

Yeah, but I think here we've we have a little bit of separation with. Are you publishing or are you subscribing a lot of the time? The answer is yes, um and so, but I think that distinction for the public api, like I wouldn't necessarily.

C

Name it that way, but yeah like can you be both ends so for an internal microservices uh messaging thing, yeah, we're all all the ends of all the things and that I think that leads us to the where we expect to be able to describe the channel or the topic, and we can't we can only describe the ends, not the wires.

C

It's it's nodes, not edges, um whereas when you're communicating with something you don't own, you are only ever going to be one end because they are the other end you're, either sending it the readings from your cute iot sensor or you're, fetching the real-time data to do something and then you're only one of the nodes. You can't be both so with the separation that we have now with publish and subscribe.

C

I kind of understand that it makes sense that it has that perspective, and I still think that maybe the read just the reusable definitions would go a long way to solving this problem.

E

Now, for sure I mean that the reusable definitions of the channel will will go a long way for sure, but um but yeah still like.

E

um I think um the problem is to persist like, uh even if we, if we manage to reuse these things, these channel definitions, but um I recall a comment: it a tweet from um james higginbotham on open api and uh suggesting that kent free called the whole conversation.

E

But he was mentioning something like the problem is that when we're focusing on paths and operations on open api on channels and operations in this in kpi and we're not using the operations as a first class citizen, if you want- and probably everything should be hanging from an operation definition like um like, we should probably be giving more importance to the operation than to the channel itself um like everything to start with, when you, uh for instance, when you start the sentence I subscribe to channel x, you define I the subject.

E

The subject is your application right. My application subscribes subscribe, so you're defining the operation first, and then you define the channel right. So you don't say you don't say in the channel I mean you can do it, but in the channel x I subscribe, I mean you, can you can say it, but it's rather weird right.

E

So probably it's that we're not giving enough importance to the operations and we're just we just have this operation id field somewhere um that you might use it or might not what about making it mandatory like uh and and forgetting about, not forgetting and and moving the importance.

E

If you want of the channel uh a level deeper like imagine that, instead of channels on the on the root level, we have operations and then a list of operations that you can do and inside each operation you define, if you're, subscribing, if you're publishing and to what channel right and then I think it might become a little bit easier to um to probably rearrange things as well or or augment things in the future like, for instance, we have published and subscribed now.

E

But who knows, maybe in the future, if we want to go to a down this path of becoming, let's say that the the spec for all kind of apis, then at some point we might have.

E

We might need to have there something like uh request, um because you want to you- want to define that this kind of in what you're doing is actually requesting something. And then this request can be defined inside the sync api, with an open api path, item or yeah, an open api path, item definition, which is the one that has get put pause on on on open api right.

E

So I don't know um yeah, uh I'm just thinking aloud and um I don't know just giving some ideas, some thoughts that I have in my mind in case some of you can pick up and develop or serves us as inspiration for something better, just roll that.

A

So to summarize, you're gonna create an issue. Yes, and we continue discussion there and see where we go and in two weeks we can kind of sum up.

A

um Okay, any other questions.

A

Okay, so let me quickly show my.

A

E

What can you see?

E

Are you in a phone or tablet? It's just.

C

It's your font is small because it's really narrow, narrow window. If you can give us a little bit more 4x3 shape yeah.

G

C

And a bit more font size.

G

B

D

E

A little bit more, I will say yeah, maybe bigger two times yeah.

C

It's yeah because you've gone white like the space, seems about square so, like first of all, it was like this and the front was tiny, and now it's like this and the front is tiny. Yeah.

F

C

I can read it now: yeah.

E

Much better yeah, okay, no, no yeah.

A

Okay, so like just, she updates, uh what's uh what changed? uh Damn it where's this now, I can't see the chat window.

A

Okay, because I'm gonna paste links real time into the chat, so uh you not sure if you noticed so recently, fran renamed the the repo with the with this pack to spec.

A

um So it's now purely just about spec and the the rest of the documents, um also a new location, where we will, for example, handle those issues for for the meeting.

A

There's a new repo called community, um so we're just um replicating or, however we you say it in english, so we're just doing what many other communities already do. So we we mimic, I think it's. The good word is mimic, so we mimic um other communities. They have. This approach, like in kubernetes that you have a one single repo called community where all the community related files are are placed, and I guess that in few weeks we're gonna enable the disk desktop to explore how the github discussions can be used.

A

I think it's interesting this issue. um After the meeting you'd like you should probably have a look. um If you want to voice out your opinion and maybe a different proposal for how we should um how often we should do releases if there should be some schedule, etc, etc, uh not much to discuss, I guess um something to just think about, and this one that's a pull request. You should probably have a look, because that's something that we discussed over last few meetings um like we, oh the size, changed sorry.

A

So um it's all about the the question that we got we're getting from people quite often like how I can contribute to the spec how changes are done in the spec, how the process looks like um we waited a bit for a for someone from the community to start um some proposal.

A

um Nothing happened! So that's why front jumped in and um we started working on it sooner than setting up the tsc and the open governance model um because, as you know already from front soon, he will be out on parental leave. So let's have this. um This process in place um before that happens, and the cool stuff is that it's not something new.

A

um That's actually something we discovered. When we worked on open governance model, we saw how graphql organized changes in the spec and it looks just awesome and intuitive. So that's why?

A

Even from the comment from uh matcha, you can see that it's mostly copy paste from graphql, which I think it's um it's. Okay, um what's the point of reinventing the wheel, but anyway, if you find some time later, maybe you have some some opinion so yeah. Please have a look so um and like kind of going back to what gerald asked about about the schemas in bindings how to get along with this, so we have a looking at this on this proposal from front.

A

We already have a strowman proposal from magic that we we need a json schema for bindings.

A

Now, it's just a a matter of finding a a personality champion that wants to drive the topic forward through each stage, show the change in action and then push it into the spec.

A

um Last but not least, some advertising from my site. Recently I published a summary about asking api in february. So what happened uh in the initiative on february what we started working on, but I think the most important is- I hope you know this already. But if not, um we completed working on the on the open governance model it's opened for for.

E

A

It's a reference, bigger, ah bigger.

E

A

Yeah what uh so it's open for review! uh All the links are in the blog post, um uh we're waiting until third 23rd, so it's tuesday, I think or monday next week, um then we'll merge and then like it's as written in the blog post. I think april we're gonna start already inside the foundation. There are some some legal documents that still front. I think, as you has to sign, but that's just a paperwork that uh it's not complicated. I guess it's just about hiring lawyers.

E

I actually just uh real time uh during this meeting. I received uh the papers to sign, so I will probably be doing it today. So, okay, cool.

A

Cool, so all is looking good. um I highly recommend our blog post, where we explain the motivation behind the open governance model um in the shape that it's, how proposed uh how the technical steering committee will look like so feel free to to have a look and last but not least, uh google summer of codes, not sure. If you know about the initiative um we applied, we got, we are not accepted, um I'm still trying to figure out. Why?

A

Because my account got deactivated and it looks like we never applied um and I didn't even get an email, uh but the cool thing. The thing is that we we we found, we found a vector into the system, so postman also applied and we pushed our ideas through postman as well, because they they were happy to to do it so, and I was already contacted by one of the students yesterday. That is super happy about some of our ideas and asking api in general.

A

So looks like I mean we were not able to get in through the front door but yeah who can stop us? Nobody, so yeah, but um but let's see, I think it's it's still. Gonna. Take a few weeks for google to accept um how many students can work for a given company during google summer of code, but yeah looks good and yeah, so we still have five minutes. That's all! If it comes to updates from my site links, I think I pasted all the links.

A

um Do you already have some maybe questions to what I shared or some other questions or of course um um I remember my ex-boss said once that it's not a shame to finish meeting before the schedule. So um so we can also finish five minutes earlier.

B

And congratulate friend on the paternity leave.

A

True true, thank you actually looking forward for it. Those sleepless nights, yeah.

F

E

Actually, for what comes before the baby is born, you know these holidays that I have before right before. I hope she gives me time to have proper holidays and she doesn't get born tomorrow.

F

A

Good luck, then, um so again, thanks.

D

A lot for joining.

A

um Next time, in two weeks this and in two weeks of course different times on uh I mean I mean we're still in the same time zone. It's just different time of the meeting I mean, but we've changed our so remember that it's gonna be already after we switch time.

A

So it's gonna be 6 p.m.

A

Our time zone. Thank you. Bye.

B

Thank you, bye.

A

C

A

C

A good day thank.

E