Find a proper name for the library

[magicmatatjahu]

generator-model-sdk can be confusing for someone in AsyncAPI community and also for people outside the community. It doesn't need the generator to work, it's a standalone library like QuickType, so we should change name of the repo and project. Any ideas?

My proposition is Modelina. It is a polish word for modelling clay. There is possible to form something (models) out of modeling clay (input data) - like in programming 🤣 . And the model is also in the name :)

[smoya]

I vote for keeping a name that describes per se the goal of the library. In this case, generator-model-sdk is not that bad.
I understand the confusion, if any, is around the word generator, but what I see is more the position of such in the project name.

What about models-generator or even modeller?

[jonaslagoni]

I quite like modeller for some reason 🤔

[derberg]

we must remember it is JS/TS library, in this word name of libraries do not have to be connected directly with library purpose: angular, gulp, grunt, vue, etc.

modeller looks strange when you write it, it is not even a word 😄
I like modelina as it sounds and looks gentle, female-ish rather than strong modeller.

[smoya]

we must remember it is JS/TS library, in this word name of libraries do not have to be connected directly with library purpose: angular, gulp, grunt, vue, etc.

Those that you mentioned are not related to any project. They work independently, meaning it makes sense to choose a unique and inventive name people can remember and know always about what they talk about.
Unfortunately, the description of this project makes it very clear:
This library is for generating models based on AsyncAPI or JSON Schema documents..
I don't get why we need to look for a name that could make things harder to understand and to be discovered by people.

modeller looks strange when you write it, it is not even a word 😄

https://www.collinsdictionary.com/dictionary/english/modeller

I like modelina as it sounds and looks gentle, female-ish rather than strong modeller.

Me, as a user of AsyncAPI, won't look ever by modelina whenever I search for the repository of the "Model Generator for AsyncAPI".

[derberg]

This library is for generating models based on AsyncAPI or JSON Schema documents.

that is the thing, library can but doesn't have to be used with AsyncAPI, can be used directly with JSON Schema, which makes it applicable everywhere else.

As Maciek stated in description, it's a standalone library like QuickType

Anyway, modelina or modeller are generic, talk about the same but 2 different languages 😄 still nobody would google for both using their names, not a problem in my opinion 🤷🏼

https://www.collinsdictionary.com/dictionary/english/modeller

my bad

---

I'm with modelina and I see @magicmatatjahu too
@smoya and @jonaslagoni like modeller

we need someone for final decision 😄

[smoya]

As Maciek stated in description, it's a standalone library like QuickType

From the README.md:

The following inputs are supported:

JSON Schema Draft 7, this is the default inferred input if we cannot find another input processor.
AsyncAPI version 2.0.0

If the goal is to make it agnostic of AsyncAPI soon, we should write that down and modify the README.
If that's a short term goal, I'm ok with modelina.

[derberg]

If the goal is to make it agnostic of AsyncAPI soon

just to make sure, for me, it is already agnostic if I do not need AsyncAPI and can use JSON Schema directly.

I'm more interested in fact why we support AsyncAPI and probably could do OpenAPI too. Why not using parser (I anyway have to use it) to get all schemas and then iterate over with modelina? What is the advantage of such an approach @magicmatatjahu @jonaslagoni ?

[jonaslagoni]

If the goal is to make it agnostic of AsyncAPI soon

just to make sure, for me, it is already agnostic if I do not need AsyncAPI and can use JSON Schema directly.

I'm more interested in fact why we support AsyncAPI and probably could do OpenAPI too. Why not using parser (I anyway have to use it) to get all schemas and then iterate over with modelina? What is the advantage of such an approach @magicmatatjahu @jonaslagoni ?

The library is built to support multiple inputs (any input actually, such as OpenAPI, but could also be typescript files and so on). We just dont support anything other then AsyncAPI and JSON Schema draft 7 at the moment, because there has not been added any processors to handle it https://github.com/asyncapi/generator-model-sdk/blob/da68fa0a8b8511e6598be39e03553d4df02d6309/src/processors/InputProcessor.ts#L15

@derberg You can use the parser directly, especially if you want to decide which schemas are generated or any other reason. If you just provide the AsyncAPI document it will generate models for all your messages but not lonely schemas. So it all depends on your use-case, what is easier for you to use.

[magicmatatjahu]

Modeller also a good name, but modelina is for me better (because it's my idea 😄). Let community to choose.

[czlowiek488]

I dislike generator-model-sdk, it is something you can not use freely while speaking.
Modeller have a meaning behind it and may be missinterpreted.
Modelina is nice.

[fmvilas]

• Typey — as in Taipei (Taiwan). Or even just Taipei, which kind of sounds like "type hey!" 😄
• Typist

I also like Modelina. Modeller, meh! Kinda but don't really buy it 😄