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

[magicmatatjahu]

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 :)

[WaleedAshraf]

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]

@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]

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]

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]

@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]

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]

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

[magicmatatjahu]

@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]

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

[smoya]

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]

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 ❤️

[jonaslagoni]

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