AsyncAPI Related to AsyncAPI Spec 3.0 release, 18 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Spec 3.0 meeting (January 18, 2023)

Description

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

A

A

Welcome everyone to this year's first spec 3.0 meeting, hope you all had an lovely New, Year and Christmas for that matter.

A

So before getting into it, is there anyone that wants to add something to the agenda before diving into it or want to introduce themselves or something similar.

B

I do I added something to the agenda by the way on this um not to be attended, but as I comment, I don't know if you saw it. Yes,.

C

Perfect thanks foreign.

A

Does anyone have anything else, no or the height, so let's just jump straight into it, I guess so before the holidays, right before the holidays, um I think was the meeting before we yeah it was last meeting. We talked about that it was time to uh to set an actual release date and the rest of the process. To that.

A

I then created an issue to discuss the specific workflow and the specific process to take um and.

A

The suggestion is that from February end of February, we don't include any more features, new features in Spec 3.0 and from that date like the end of February.

A

The only thing that can change are review of and minor edits of value, already existing changes and then finalizing all of the tools to get them up to date with spec 3.0. So when we release in June, all of the tools are already ready to accommodate the new version.

A

And, of course, we can still remove existing features or reject them from the spec in case that happens, don't think it will. But at least that's still, the option.

A

Up until now, there haven't been any rejections or problems or uh comments where it shouldn't happen that we shouldn't go with this approach, um but just for the sake of it. If anybody have anything, they want to add uh to the discussion here. I think we can bring it up.

A

C

Is there any um concept of an end of life for the sort of the 2.x version of the spec I mean I? Guess we're going to stop making adding new features to it. So that's kind of implicit but yeah I'm just wondering. Is that part of the schedule that the the idea of winding down changes to 2.x, or maybe that just we keep it just by virtue of not making adding new features, it kind of implicitly becomes deprecated.

A

Thank you, we don't have and it haven't been brought up yet and I. Don't think we have any issue for it either. So there's there's no protocol yet of what to happen. There.

B

Yeah I'll I'll just uh continue with the trend that we've been doing right. So if we are in version two, we don't maintain version one anymore and if we're in version three, we don't maintain two anymore right. So um unless I mean we're not maintaining a that's work, so I was thinking on security issues and all this stuff, but yeah what security is am I.

B

We might have right on our American flight, so so yeah uh I, don't have any any uh I cannot come up with any reason why we will maintain version two for a long time. For a longer time, instead of you know, motivating people to migrate to version trees yeah. The idea is that yeah we're gonna, we're gonna, have person two and version three we're living together for a while, and that's that's. Okay, that's completely fine, not everybody has to migrate, but yeah right.

B

If we want to move forward I think we should be. We solve this top in developing or improving version two right. Otherwise we will end up with two with two spec. Basically, especially, regarding this pattern. Subscribe stuff will make things more complicated. That doesn't mean that people will should stop using it and that our software will not understand it for sure we should give Steve still give support to uh version two on all our software uh for I, don't know years, most, probably so, but yeah and then at some point.

B

We just I think the the issue will arise whenever when it's the right time, then someone will probably complain like do. We have to support this anymore on the parts and all the tools, and then it will stop being supported at some point, but yeah like I, said I think it will be in years or it should be perfect, so we give time to people to properly migrate.

B

Thank you. So yeah.

A

I agreed: was there anything specific you wanted uh to.

C

Bring no I was thinking out loud.

A

A

um All right so taking this further, uh should we set a specific date where this is accepted as like. This is what we do or like give people another week or, but they are only six weeks left until no further changes can happen, so it's kind of like yeah not sure how to proceed there.

B

A

Do you mean when do we say that this is the approach we take.

B

uh Yeah, that's a good point, I think yeah. We still. We should be priority to this issue. Right uh I mean we need the maintenance so be giving priority is easy. So so we decide as soon as possible because it's January it's past mid-January now. So yes,.

A

Until freeze period, if.

B

Yeah I know I know that's trying to be more so yeah, um actually I'm giving priority to everything, really good respect so yeah, so that we can have it ready for for next month. um I! Guess it's on the issue, but yeah! It's uh we we suggest, uh which is. We should just give it a priority.

B

um Can you share the link to the YouTube, please or yes, now that you haven't already there I'm, just being lazy here.

A

B

A

I think it would make sense to to set a specific date that, unless anything specifically is stated that this shouldn't happen, we just accept it from Friday or next week.

B

I'm gonna just uh ping maintain this one by one. Let's take advantage of that, we are only a few right there. Manually I'm gonna, make sure that I think everyone manually and and to ask them to leave a comment there and replying to with what it should be done. All right. Remember that uh the the idea is that we released in June. So if we postpone this to March, for instance, instead of February, this means that we give less time to software and people to actually and.

D

B

To actually try it and test the spec or we move it to September, but we listen to in September sounds like uh like a suicide here right after the right after the summer, right, yeah, so yeah I think we're yeah. We just it has to be February but yeah. That's my opinion.

A

I also talked with Lucas about from end of February or when the freeze period kind of starts. I. Think these meetings are gonna change a bit to include, or maybe we start a new meeting. That depends, but then we can use these meetings as kind of office hours.

A

So if you want help supporting version free, if you have a product, if you are Library, not sure how to do it or something is not clear, you can, for example, participate in these meetings and get the help to migrate or to support the new version and ask questions there.

A

Yeah, that was a little sad here, especially since there's probably not much. We need to discuss related to the spec itself, unless it's very specific for one one specific issue but yeah we can bring that up later as well.

A

Anyone has anything for this specific item.

A

Before we move on.

C

A

Friend, do you want to bring up yours now.

B

um Yeah I was leaving the cabin there.

B

um Well, actually, I want to discuss this with Lucas as well, because it was all triggered by a comment with accounted from Lucas actually, but he's not here so yeah um but anyway, let's discuss it because I I want to know your opinion here so because I'm also not clear on what to do here. So it's got a great point, even though he's always wrong, but don't tell him.

B

Don't tell him that he's that he's right.

B

uh So this issue here is about separating servers. Right now we have servers, as uh you know like like this. We have a websocket server, a Kafka server, a Kafka, Brokers, everything and so and so on, and so just a little bit of context. The spec is about defining the application right so so far. This is what we have spec defines a specific application and so servers.

B

There are right now a mix of servers that you can connect to like the Kafka broker, so your application might connect to a Kafka broker or it can be a websocket server, for instance, that you're not connecting to you're. Actually the server your application is the server right.

B

So that's a weird mix right, that's a weird mix in the beginning, we always defaulted to like if it's HTTP and websocket, then we assume that uh the application is a server and um and if not, then the application, which is a client connecting to a broker or another service right, but the more we develop tools, especially Glee, for instance. In this case, that's why it came to to my table is that um I may want to build a client that connects to a websocket server or to an HTTP server right.

B

So I may not be the server myself. I may be the client so and I still want to list it there that I'm going to connect this websocket endpoint somewhere. So if I put the server there, we need to make a differentiation means that if we, if we add the server to the to the list of server- and it says websocket blah blah blah- we need to make a differentiation there like. Is it that I am the server or is it that I am deploying that who's connecting to that server right?

B

Everyone follow him so far, so that is, um that is more or less uh the context right. So in this pull request, what I'm doing what I'm proposing is that um we separate servers. Basically we split it in two right. Then we split it into um into provided servers and used servers right. So if I am, if my application is providing a server like I'm providing a websocket server on an HTTP server, then um I put it into the into the provided service.

B

But if I'm using it, if I am the client right, uh then I put it into the use servers. But um that is.

B

uh So Janice, what are you saying? Maybe endpoint and server, make more sense that use server and private server respectively.

A

I I just wanted to just keep. Keep that in mind until you ask for questions and then I can answer it. That's.

B

Okay, that's okay! Let's interrupt me whenever whenever needed and then wait for it.

A

There's just provided service and your servers like that keyword yeah. This is weird to me like it's like I, understand the concept behind it. I, just don't like the keyword itself. Okay,.

B

You mean the name yes and then wait until I. Explain to you why endpoint is is even a worse idea, because then point is a way more overloaded term right.

B

So you're gonna really be careful with uh with that point, but yeah that's given that's also I think that was another discussion and I'm not sure if it was with Jason. Actually um so so yeah one of the ideas was that uh that we still keep servers as it is, and then we add two optional ones uh where we reference them and say like this is provided. This is used blah blah blah right.

B

um So that is uh um oh yeah yeah. The thing is that this got a little bit more complicated because since version three, um we are talking about um a different kind of HTTP file.

B

So we're talking about the file and it's going to give a file that doesn't Define an application that actually defines um a set of resources set of channels, messages or you know, without operations, without public subscribers and obviously, or anything like that, and actually that was triggered after my conversation with my thinking out loud episode with Dale right I think it was one of the first ones and uh that they were using async API.

B

They were hacking using kpi right uh to Define, all the all the channels and all the messages in this Channel and I think they were using always subscribe or Publix or whatever it doesn't matter, because yeah, it was just a as a way to list all the channels, all the topics and all the messages inside, um but it you know the operation wasn't important because they they were not interested in that they just wanted to Define a menu of uh of channels and messages and other stuff right, so so yeah.

B

So um so we're starting to talk about this kind of new kind of document right.

B

um So in the in the new kind of document, where uh it's not representing an application, then provided servers and used servers, don't make sense anymore because who's using that service or who's providing these servers there's no application. It's just a menu of things. So in that case, what I'm proposing is uh or what I'm suggesting that we can do here is we need to identify the identify, the kind of documents right.

B

What kind of document might be an application or it might be something else at the main whatever domain might be, and many of things collection like like I, said here: it can be a collection, a menu Library, whatever name you want to come up with um and then in the case of the application document, providing servers and new servers make sense, there's no servers, property playing service property, but in the case of uh domain there will be servers, but there will not be provided servers and used servers.

B

So uh so that is like when I saw music, it was like. ah We got a problem here because all of a sudden we're introducing a new um a new field here called kind just to differentiate the kind of Facebook profile we're talking about which might make sense. I'm, not saying it doesn't put yeah, it adds more complexity and- um and another thing is, um is that we split yeah that we split basic DPA object.

B

The root object facing API into two different ones, right so into application or the main object, which has a little bit more uh complicated uh or, let's say ugly. If you want thing, is that just because of this? Just because with reference in servers here, but we don't know what are we doing with these servers right, um almost all of a sudden and because of this, and because uh we have a new kind of file, which is uh the menu right and the menu was agreed in previous pull requests that it will be triggered.

B

You know the menu Behavior will be triggered if there are no operations. So if there, if there's no operations, it would be considered as the collection a menu of things right.

B

um So in such a case, just because we have this thing with the servers- and this other thing about having not having operations being a menu or not doing a menu being an application not being obligated, uh we found we find this um conflict. You know like what do we do like? uh If we forget about provided servers and new servers, um then we still have a problem.

B

We still have the problem that I uh that I said before um am I connecting to a websocket endpoint or what's our websocket um server or or mi in the websocket server, but this is still installed if we um try to solve it like this, for instance, uh somehow like this, um we still have the problem that um these two properties should not be allowed.

B

If there are no operations right.

A

How many, how many protocols require you to know whether it's a like a remote provided server versus something that you provide I.

B

Mean in theory, anyone in practice is http websocket right. How many people actually I mean you can write a Kafka server yourself if you want, but why would you do that right, like you will use a broker password broker, but um but HTTP websocket, it's pretty common. It's like you write your own server right. It's actually the usual thing right. You write your server.

A

um Have you tried using just a question to have? Have you tried using the bindings to specify whether it's a provided or used server.

B

Yes, that was uh that that was investigated in the previous conversation. I, don't know if it was uh here.

B

Well, somewhere, I'll explain what happened so we explored something similar and it's that we uh I propose it at some point that we annotate the server with a kind. Actually, it was, and now I remind uh well actually right because said here take the time to extract it.

B

This is yeah, introduce a new kind property on the server object. So we can. We could use something like this kind, local kind, remote or whatever names that you want to come to come up with right. So this is that you are providing the server. This is that you are connecting to a rebound server right. So problem with this is that this makes the server object uh impossible to reuse right.

B

So if I extract This, Server definition to a separate file and I have two applications pointing to the test server, one will be the server, but the other one will be. The client and the client is uh the client is, is seeing that this is local, that this should be that the clients will be provided in the server, which is not correct right so right and then- and the reason is that the the property of a server being local or remote is not a property of the server itself.

B

It's a property of the relationship between the application and the server you know. So it's a it's a trade of the relationship uh imitated too right. So it's what what am I the application. What is the application?

B

um What is the? What is the application to the server right or what is the server to this application? This is a uh am I the server and the application at the same time, or is it just two different things that are connected right, so this trade, it'll trade, no trade, doesn't uh get incubate rates. You know these uh feature trade. Whatever uh characteristic this characteristic is of. There is a is a thing of the relationship. It's not the thing of the server or it's not the thing of the application. You.

A

Know so right, okay, so so the main reason why you want to have these two root server keywords is because you want to have reusability between them. Instead of having that specific, the.

B

Same that we have.

A

The same problem we have at operation.

B

Yeah exactly yeah, so the thing is that uh if we put it like this, you cannot reuse this server. This called server definition right because the server yeah cool server will be fine, it's local, but the client will be seeing local and that's not correct so and you cannot override it. If we could do this dollar ref and then along the dollar rev put some more properties to override the kind property. Then it would be easy to solve, because we could override this thing right. But uh but we can't.

B

Right so so yeah. um My other proposal at the time was that we split the current servers into remote and servers right. So we have servers and remotes. Both of them are the same thing. It is a server in the server, but these ones are understood as uh remote servers right.

B

um It's you think it's the same as es servers and provided servers. um It's the same thing. It's just that in my proposal, before what I'm doing is I'm living servers, untouched and I'm, just adding two more lists right to more um properties that you can add and specify. If one server is, is removed, it's a provide, it's a used server, but if it's a provided server, if it's mobile right, um but it's the same concept in the end, it's just trying to play with it in in different ways: um foreign.

B

Somewhere but I don't really wear. One thing that we can do is that we can default servers to being remote. Servers used servers right like a broker, and we only add this one provided servers right so so that you specify like this is the default. So if you're using Brokers, you don't have to add this one. But if you are using websockets or I mean you are a websocket server or you are an HTTP server, then you still add this one to mark this server.

B

As it's me, it's been implemented, This Server right, it's not something we want right, but um yeah, so that is.

B

That is it so far any questions so far.

A

And the reason you want to keep the servers keyword is because you want, for example, channels to be able to reference just one specific server definition right.

B

Yeah and and actually just to make it uh less problematic, let's say um in the other, in the other approach, where I have servers and remotes it's the same thing here, I'm just uh defaulting to the opposite, so defaulting that servers are actual servers like you are creating a server you're. Exposing a server yourself and remotes are that you are the client at that service, so so yeah.

A

Have there been any discussions regarding adding a trades for servers instead of having this.

B

No, no, it hasn't been.

A

Because that would kind of that would solve your reference problem per usability, where you can still specifically provide the kind of operation keyword and still reference it accordingly.

B

huh How would you solve it, I'm, not sure.

A

Because then, your server trades definition would kind of like that, contains all the information, the URL, whatever security whatnot.

A

And then you can still have the let's just say we use kind, for example, local or remote.

A

Then you can still from across two uh to our async API files. We can still reference uh one: that's a remote um websocket server and one that's a local websocket server. You.

B

Can still share.

A

The information across them right, but.

B

Where do you, where do you apply the trade like like if I, if, if I, have a dollar wrap here in another file, not in this file, if in another file, I have no.

A

The trade the trade is a dollar. If so, you would still have your uh yeah.

B

Yeah, yeah, okay and then I can apply it right to overwrite, something on the obvious. What you mean? Yes, that is so cool yeah. That's another solution.

B

D

Sorry, could you repeat that is so: are we playing? Are we applying the kind to the operation yeah.

B

So that would be yeah. Let me just uh type an example: Maybe um I think it's gonna be easier.

B

um Well, yeah I can just keep this one, so, for instance, I can have something like this. That is kind of local um right. um Well, in this case, let's take, for instance, that this is a websocket server right and.

B

Blah blah blah whatever all right so thing is that we have a websocket server here and for this application that we're defining this is local, but in another file. What we can do is that or what what um Genesis proposing is that we add trades here. So we had. We also have a trades property like we have in other parts of the spec, and so we can just have something like uh like this, and this would be. It will be something like this right. Oh.

A

So but the protocol and the URL are part of the trades and the kind are explicitly there.

B

ah You mean the opposite. Why.

A

B

Would You Do It reversed because.

A

Because it's the kind property that are explicit for this specific application that is either remote or a local one.

D

Yeah I would agree with that. You would want to have like the kind be located on the operation, because the operation can interact with the a server in either a a remote or a local kind of way.

D

So exactly in the situation that you were talking about to make to make servers reusable if you had like a sort of a.

B

D

Of servers, you could have some operations interacting with a with in a remote way and some interacting it with it in a local way. So you would want to label that method of Opera that type of operation um on the operation itself and then make a reference over to a generic server object.

B

So what you mean is that we've put everything here: yeah.

A

B

That, right and.

A

That's your reference.

B

Then my question will be: wouldn't it be better if we just have something like you see, servers we can have local and remote and then inside here I will just Define the whole thing right.

B

uh Okay, a second.

D

Yeah but I think then I mean we're talking. It's.

A

D

A

That that kind of needs to be solved right because between local and remote you still have the same URL. You still have the same protocol. You.

C

A

Have the same security, but it's the it's a car and I mean to me. It doesn't matter whether it's a or b here, but you still want to reference those uh those common information for the server, because you don't want to duplicate that information right.

B

But you're not duplicating like remember that you are in some other document say this is this? Is another document right uh-huh.

B

So here what I will do is I will point to this somewhere, not this, um this doc, okay, uh servers and it will be local because I know it's local there right, uh local, uh well, actually, I'm missing this yeah I'm just missing the idea. Of course,.

B

Right and that's what we have here so.

B

My application will know that it's remote because it's under remote, my application, will know all the whole definition of the server because I'm pointing to it, and there is no kind or anything here which effectively translates to what I was trying to achieve by removing servers and just have.

B

Servers and remotes yeah. That's why I did it?

B

That's why I did that, so that we don't have to because the thing is that if we, if we do it this way, then I mean it's weird, because we we would have to make trades property mandatory right.

B

Otherwise, you can have a server like this.

A

No I mean it's it's up to you whether you want the usability. I mean you're, going to duplicate the data. All you want it's the same with reference here in the remote and local. You can decide to use it or you cannot like using reference there. It's up to you, but.

B

Then you mean that I can have the URL here as well.

A

I mean it's up to you: it's the same with trades that we have in channels and operations. Okay,.

B

A

But if you want reusability, you can use trades and a reference that are laying our specifically specified in components.

B

And then I'm curious, why? Why not like this? Why not like I, just specify everything here and I just make it like? um You know kind of right, well, yeah same thing because yeah, it will also yeah yeah. It will come with a with a dollar ref yeah.

D

Yeah, if you're coming in, if you have a directive server, so to me, it makes a lot more sense to have the kind attached to the operation since that's how things will come in and then you dollar ref over to the to the server.

D

uh But you specify how this particular operation, like you know. If it's a publish operation, then of kind uh remote and then you dollar ref over to the to the server that could potentially be in a directory and that way you have server, reuse.

B

If we do it like this, then every single operation will need to have this specific property right, like marketing is well.

D

In the same way, I mean you can make it optional in the same way, like you say really, this kind property is only applicable for web services and web sockets or HTTP. So you can make a default. Have it be a a remote and if people really need this functionality for uh websockets, then have them specify.

D

B

D

What I mean by.

B

But what I mean by every single operation is that imagine that I'm documenting um my website with API I'm the server and we're defaulting that everything is remote. Then all my operations in my file will need to have the kind attribute you know. Can.

A

Someone explain to me why we're talking about operations.

D

Well, I guess, because that's the the whether something is local or remote is relative to uh to an opt to an operation right like a single server from one perspective is local, but it's also remote to a client that's connecting to that to that same server.

D

So if you want to have the you know that that one server be reusable for both clients and for the application itself in case, let's just say, it's websocket server, you can't have the server have the kind defined on the server itself, uh because that's not reusable right, because, depending on your perspective, the the server is both a local or a remote server.

D

The only way you can the way that's differentiated is how the a one particular operation interacts with that server. So it makes sense to put the kind on the operation, not the server itself.

B

I agree with monster fit, but what I don't agree with is that it's it's something about the operation? It's not about the operation. It's about the application, it's a relationship between the application and the server. So is the server the same as the application, or is it something remote? You know it's not about a specific operation right. It is not about sending a message or receiving a message it's more about like. Where is the server to me? I am the application right. So what is the server to me? Is the server with me or I?

B

Am the application, or is it server uh somewhere else right and then.

D

You define the server within the within applications, async API, but then because we have this directory concept. That's coming in B3 you're abstracted away like your application, doesn't Define the server. The servers are free floating. So right you have to.

B

Right right, so that's that's. Why that's why I wanted to separate it into into this? What is it not this one? uh It was here. So that's why I wanted to separate it, not with kind but to split it into two different properties right. So because, if you split it like this, then this can be a dollar ref to this uh other kind of document. You know this directory document uh where you have the server defined it doesn't.

B

The server definition doesn't contain any information if it's local, remote or anything, because it's not something, it's not the property of the server so but this will be implicitly defined right or we can rename this to locals or whatever, whatever other name right, uh but this will be local servers, and this will be remote servers so here effectively in my application, instant, keep a file. What I'm saying what I'm doing is all the local servers. Are this all the remote servers? Are this right, um they're.

D

Also yeah I mean: do you think that that I mean that's a pretty wholesale change right? Because if, if you're saying that Brokers are I mean I, don't even know 70 of things now you're going to have to explain to people a lot of people, the difference between difference between servers and remotes I. Don't know if that's necessarily.

B

That's that's why I wanted to introduce the other concept right, so it's like servers. It's just servers, there's no differentiation right and then we do it the opposite way. So we only do it for providing servers right um or we can get rid of this right, but uh we can do we can use this so only for those who are providing servers, namely uh HTTP websocket servers right, so they have, they will have to do it for the rest of the people.

B

uh It will just be as as easy as removing this and just just lift the servers here right, as as it is, as it is right now right, so that will make broker people happy.

C

B

Yeah the reality is that so I know that this is in kpi right and most of the thing here are, uh you know our broker stuff working through this stuff, but you.

D

Know I'm thinking about to think about right.

B

You know I'm thinking about the roadmap right, uh so it's about any kind of apis right, so if we ever get into um rest or not even rest websocket as well right, but if we ever get into the standard to Define rest apis right, um if we become the default, let's say then the majority will be rest would not be Brokers right. That's right! So so, even though I'm I'm sad to say this, because I would love more people to be doing asynchronous stuff and not that stuff, but that's the reality.

B

I mean that could be the reality. The reality is that, right now the default should be to uh make it easy for broker people, let's say because the majority will be for brokers but uh but yeah, and in this case Brokers will be always remotes or YouTube servers or whatever you know so yeah. Actually, this suggestion of using provided servers and use servers is coming from this issue. I think.

B

Yeah yeah, so it's.

D

Kind of yeah I mean it's interesting. Man I think I just need to I need to think about it. A little bit more I mean clearly like the less I'm just thinking about the education process. For for people, how would I explain the difference between a provided server and a used server and what you know the case where which maybe it's just a New Concept to me and I'm, not fully rocking exactly how? How I would do that so I guess maybe I'll, maybe I'll be quiet and.

B

uh In in your case, in your case this, you will have to do nothing because yeah.

D

Yeah, that's certainly appealing because I love doing nothing. So that's great.

B

Because 99 of your users and your customers are not will not ever have to write anything with this, this right.

D

B

I mean I still care about the spec as.

D

C

D

I'll think about it more and maybe I'll comment and.

B

Okay, so yeah, so so give it a thought. uh Also. I don't want to forget that there is a comment from a long comment from uh uh if we look as um splitting all his thoughts into uh into this and the conclusion right.

B

um Let me just uh that's a lot of things yeah, uh so the thing is that another proposal was that we create another spec, so we create another spec just for the catalog or the directory kind of documents. So it's a separate spec and we maintain it separately. Most of it will be common right, but it's a separate spec. So then it's easy because uh yeah it's a different thing right, but um but we don't. We don't need that, of course, and we're not gonna I.

B

Don't think we should be doing that now, but that's a that's another option, um and so Lucas is saying that uh that we should probably be saying that basic apis for API interface right. We should not be staying there. They think apis to Define applications um or to define the a directory of things. But it's is that it's actually, if I understand correctly, uh that's why I wanted to have Bluetooth here but yeah.

B

So, but the idea, if I understood correctly, is that we don't uh we don't make this decision at all like. So, let's give a document, it's just a some stuff defined there like it can be, for application can be a directory. We don't Define that we don't say we don't mention uh application or anything in any place of this bank. We just leave it uh to the human using the document to know what kind of document it is.

B

What kind of thing it is uh defining right so is the he argues that it's always um so, for instance, um like I, really do not do not understand why we need the property to say kind, domain or kind, uh catalog or kind uh directory or whatever, no matter working on location and location. Why tools need to behave differently depending on what plug was provided in the end? It's it is human that choose a tool and uses it right. So it's a giveaway document. Maintainer know what interface they're documenting.

B

So they know that they should not use it as a collection as a domain. We should just explain that separately documents will be created with proper title and description as.

D

B

Be a documented users know from the title and description. What document is it and what is its purpose? No flat needed, um and in the case of Glee, for instance, if I have Glee and it's capable of being either kind of server, then I do not think it should be on spec level. What it's? What it is told if it's incubate document is for finder server, it will be a conscious decision of the user maintainer to provide proper Flags to the tool to get desired result.

B

So you define everything, but we don't say if it's a per application and if it's a collection of stuff or what is it, we don't. We don't say that it's just an interface right and then, for instance, of my framework, I just say like use, use this sdkp file and I have also to say like, but use it as an application definition right.

B

um So so that everything's clear there or use it as a as a um or use it as a collection of things right. So if you try to, for instance, use the document as a collection of things and if you have a tool that can that allows you to use the document as a collection of things, there's a domain or whatever you want to call it.

B

Then if it finds that there are operations, it will simply ignore it. It doesn't fail. It just ignores it right, uh because this tool is not meant for it's not meant to interpret uh operation and uh and if you are trying to create an application- and there are no operations, then your applications will complain that you don't have any operations defined right, that yeah you're trying to build a client or a server or whatever, and uh but you have no operation.

B

So how am I supposed to implement anything right um so so yeah like up to the tool? It's another way. It's a! We delegate this responsibility to to the user using the tool right. We keep the document the same for everything as it doesn't have any specific meaning it's not for application or it's not for uh collection of things.

B

My only concern about this is that we should probably not be saying API or interface, because we had this inspected recently on slack. What most people understand by documenting or defining the interface is precise. It's precisely the opposite. It's precisely. What do we have right now on messenger is what others can do with me.

B

So I'll be careful with this, with using the API and interface words, so I I understand that it's still interface but yeah, not as team as we usually see it so yeah. So there is, there is a we can be more specific or we can be more flexible there and we don't Define that and it's up to the user to interpret it the way they want.

B

The document is just there.

B

It's a Lewis definition.

B

Talks about it.

A

Sounds like I agree with Lucas, so I have to I have to read his comment. I guess.

B

Exactly sounds that I agree as well, but and that will facilitate things a lot on our side to maintaining spec.

B

But I'm fearing I'm, like I'm, fruitful, that we are living things undefined and uncovered and they're more uh improper uses of the spec will appear improper, as in like improper ways of understanding the spec and that we end up with different tools interpreting it differently. And then these tools cannot really communicate with each other because they understand the respect differently, because it's it's loose on that on that side. So.

B

Pros and cons, I guess but I mean I, don't have a specific case. It's just fear. This is the fear that we might because we're not specifying it. We might leave the door open to you different interpretations of respect right. So specifically, if we don't clarify what what do we mean by interface.

A

Specifically, I mean that specific, like API and interface, probably have to be explicitly stated in the spec from version three, with a specific explanation of what it means in this version. Yeah, because it's very very different from what you might be used to.

B

A

B

A

Education problem, another.

B

I mean public subscribe was an education problem.

A

Yes- and we haven't done well educated about that.

B

It's complex: it's.

A

B

People don't read including myself, yes, people, don't read, I mean you, you usually not until you have to that, didn't exactly not until you have to, but you probably complained before reading or just uh throw it like. This is, and it doesn't work before actually reading it there um and before actually asking so, let's say yeah like there's this pros and cons like we need to I mean if you read, interpret it's because you're reading the specs. So actually this is not really a problem.

B

uh If you read the work, interface or API in the spec being defined, then it's another problem, because it means that you are reading the spec.

B

So the problem is: when you not you, don't read it but yeah. But when you don't read it then it's. The problem is that you might understand, though. Well you have this problem anywhere, uh even if we make it explicit that it's for application, whether this is for blah blah blah. If you don't really respect, then yeah, of course. Yes,.

B

B

Pros and cons uh uh and yeah, and in the case of we don't we Define the interface, then yeah probably provided servers and used servers, don't make sense anymore.

B

um So there's, uh for instance, if I'm using my framework, um yeah I will have to go to the config file of my framework and say, implement this server or use this server right.

A

So it's not enough.

B

That of extension, exactly but yeah what we're saying that we don't put on the spec right, it's a um because if we can put it as an extension, then why don't we put as part of the spec right.

A

Because, if it, if it can't live as an extension, it can't live as a in the spec right I.

B

Mean yeah I mean it's.

A

B

Can look at it as an extension period? We just have 18 compared three and the rest is it's just an extension? Yes, um but uh but yeah like I, don't know yeah, it can be an extension, can be a configuration on your tool can be um thinking now like, for instance, if we use the generator to generate documentation.

B

uh That will probably have to be near parameter that you can pass.

C

B

You will have to specify that this servers are locals, I mean local servers or whatever you want to call it. um Yeah.

A

All right, three more minutes, any last remark for that issue.

B

B

Please leave your ideas there, even if you feel that, like uh these guys, seem to know what they're doing and where am I to people coming there well. uh First of all, we don't know what we're doing we're just trying to do our best and uh and yeah. So we we welcome anyone everyone to leave a comment there, so yeah for real.

B

Actually, I changed from servers and remotes to provided servers and new servers, because someone in the other in the issue in one of the related pieces, uh proposed that and I was like. Oh, maybe that's more specific, that's more. You know like even being more um explicit than just celebration agreements.

C

A

B

Right in the end, names will not matter once we, we have Studio uh allowing you to create HTTP files without touching the single line of code.

A

It's still better, especially if you don't use your studio right.

B

uh But it will, it will only matter to those who want to write respect manually, which I'm assuming here, that they will be reading this back.

A

Yeah then we're back to it that they will read the spec whenever they reach that point where they have to learn about used and remote servers. No.

B

They don't have to, they will use, they can use the UI to to do it properly. To do it uh without having to learn anything only those who really want to type them to type it will have to learn it, and it's up to you, you have tools, if you don't use them. It's up to you.

A

All right, that's that's! The final word I guess so. I'll make a new issue for in two weeks again, I think unless we want to start increasing the but I haven't heard any requests for that, like increasing the frequency of the meeting. So uh let's just keep it in two weeks and I guess: I'll see you there thanks everyone thanks.

B