Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.0.0] Should we have messageId and name fields in Message Object? #862

Closed
magicmatatjahu opened this issue Oct 26, 2022 · 12 comments
Closed
Labels
❔ Question A question about the spec or processes

Comments

@magicmatatjahu
Copy link
Member

We had discussion about it in the 3.0 meeting - https://youtu.be/H5P-gBwdFs0?t=506 (started from given second - about 25 minutes).

We wonder if we need name and messageId in new v3 spec. We can treat keys in channel[x].messages object as messageId. This means that messageId (object key) then will be unique against the channel and not against the specification/application. We should discuss whether the change is a good one or whether we should rather leave messageId and name. WDYT?

cc @jonaslagoni @fmvilas @smoya @derberg @dalelane @char0n
You are also very important @WaleedAshraf You added messageId to the specification and we will be very grateful if you will add your 2 cents :)

@magicmatatjahu magicmatatjahu added the ❔ Question A question about the spec or processes label Oct 26, 2022
@WaleedAshraf
Copy link
Contributor

As per current spec messageId is already required to be unique across whole document.
https://github.com/asyncapi/spec/blob/v2.5.0/spec/asyncapi.md#fixed-fields-14

The main diff will be that currently, it's optional. You'll have to make it required.

@magicmatatjahu
Copy link
Member Author

magicmatatjahu commented Nov 9, 2022

@WaleedAshraf Yeah, but that messageId will be indicated by map key, where message is defined, so it will be required but you won't have option to not define key of map - in other words, messageId will be always set.

However, thinking about it second time I think that messageId is very important when you have registry for your system (in v3 creating registry will be easier than in v2) - each app which will reference to the registry should "share" this same message and messageId can indicate uniqueness of message in system.

@smoya
Copy link
Member

smoya commented Nov 23, 2022

From #796 (comment)

Let's check the definition for messageId field at https://www.asyncapi.com/docs/reference/specification/v2.5.0#messageObject:

A machine-friendly name for the message.

Now let's think, Isn't the messageId right made for that purpose?

My suggestion is to go further and deprecate name field.

@smoya
Copy link
Member

smoya commented Nov 23, 2022

Another discussion that should take place (unless there is a clear reason) is why do we have title. I would either leave name or title, but not both.

@magicmatatjahu
Copy link
Member Author

@smoya title is a human friendly readable value, but name is machine friendly, so title is used usually for documentation generation and name for code generation.

As for the message fields, I would leave the messageId and remove the name because they currently serve the same purpose and the messageId has the + that it must be unique in the document.

@char0n
Copy link
Collaborator

char0n commented Dec 19, 2022

Looks like for messageId, it's best to leave it untouched and deprecating or removing name make sense to me, after reading reading arguments in #862 (comment) and #862 (comment)

@fmvilas
Copy link
Member

fmvilas commented Dec 23, 2022

I would completely remove it instead of deprecating it. We already use keys as ids in v3.0.0.

@magicmatatjahu
Copy link
Member Author

@fmvilas

I would completely remove it instead of deprecating it. We already use keys as ids in v3.0.0.

And it's not true 😄 Why? For operation of course, because we can define operations in one place, new operations section, but messages you can define in each channel, so it means that id for given message can be different - if is used in multiple channels, and I think that people can reuse given message in few topics/events. So I will left messageId.

@fmvilas
Copy link
Member

fmvilas commented Apr 13, 2023

Sounds reasonable. Can we then just remove name and rename messageId to id? The "message" part is redundant IMHO.

@smoya
Copy link
Member

smoya commented Apr 13, 2023

I think this wasn't include (for some reason) in #691. Considering the freeze we set up, I wonder if we shall discard it for 3.0 and rather be a candidate for 4.0.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

@github-actions github-actions bot added the stale label Aug 12, 2023
@jonaslagoni
Copy link
Member

messageId has been removed as of v3, I guess that means we can close this issue now? 🤔

@github-actions github-actions bot removed the stale label Dec 7, 2023
@smoya smoya closed this as completed Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
❔ Question A question about the spec or processes
Projects
None yet
Development

No branches or pull requests

6 participants