Design of internal channel handling can lead to strange effects

[juergenRe]

Channels can be either disabled, primary or secondary. Both deleting or disabling a channel lead to the same role entry. But the latter one keeps its settings for the case the channel is reenabled.

On the other hand, --info does not show any disabled channels. This might lead to the situation (especially during testing), that the system refuses adding a channel because there is still a disabled one with this name located anywhere in the list.

It seems, that disable/enable has now been replaced by add/delete, so these command options are not very consistent any more. However, I don't know if disable/enable is still used by someone.

At least I suggest these improvements:

1. Clarify the role of an deleted/not present channel with "absent" instead of disabled.
2. let --info show disabled channels so we can get aware of them
3. let deleteChannel output an additional message in case the channel to be deleted is absent. Deleting a channel then also will delete disabled channels.

The best would be to remove the enable/disable commands.
What do you think about it?

[roberthadow]

Hello @juergenRe --

If there is a disabled attribute, then there whould be a distinct enabled attribute. That's yet another bit to keep track of.

I suggest going back to basics: CRUD.

(D) A channel may be deleted and therfore no longer exist. The Meshatastic default is the existence of one primary channel. A comand to delete simply dumps all the attributes for that channel.

(U) One may update the name of the channel and its other attibutes.

(R) One may read the attributes of an existing channel. If one tries to read the attributes of an nonexistant channel, then absent is as good a term as any.

(C) Create One may write attributes into an unused channel, enabling it.

If there is a particulalry good use case for retaining the attributes of channel without permitting its use, then, fine, add an enabled bit. It seems like unnecesary complexity to me, though.

[roberthadow]

@juergenRe --

Consistency is important. How about using the same terminology as the GPS? NOT_PRESENT

[juergenRe]

Hi Robert, thanks for your comments. I was a bit locked in my testings the past days, so I answer a bit late...

Concerning your first comment: its not to add one bit for "enabled" and one another for "disabled". Its already the question what is needed by the users: do we want to deactivate a channel but keep the attributes for later? This is what the disable implicitly does and it interferes with what deleted means: the channel completely disappears. Obviously, a deleted channel has to be handled sometimes differently to a disabled one.
If we want to distinct these 2 cases we will need to add one status designation.

To come to your second comment: For me OK like this. The role attribute then would carry these values: {"NOT_PRESENT", "DISABLED", "PRIMARY", "SECONDARY"}. Any channel carrying "PRIMARY" or "SECONDARY" is implicitly enabled, which is good for me.