[squeezebox] Add new channels for additional tags

[mhilbush]

Resolves #13353

Added channels for the following:

• albumartist
• trackartist
• band
• conductor
• composer

Signed-off-by: Mark Hilbush mark@hilbush.com

[jlaur]

Thank you. Looks simple and good to me! I have added comments for a request to use camelCase for the two multi-worded new channels.

[mhilbush]

Ha ha. I actually started down the camelCase path. But I changed it to be consistent with the tag naming convention in the LMS, and also because I didn't want to change remotetitle and coverartdata to camelCase, as that would be a breaking change.

I admit that the binding is a bit inconsistent in how the channels are named. Some are camelCase and some are not.

But I'm happy to change the new channels to camelCase if that's the recommendation. Just let me know.

[jlaur]

Ha ha. I actually started down the camelCase path. But I changed it to be consistent with the tag naming convention in the LMS, and also because I didn't want to change remotetitle and coverartdata to camelCase, as that would be a breaking change.

Correct, it's a pickle staying consistent and conforming to naming conventions and at the same time without breaking backwards compatibility. 🙂 However, one thing we shouldn't do is adopting naming conventions from the API's we implement in bindings. We have our own, making openHAB consistent across bindings and being API agnostic.

I admit that the binding is a bit inconsistent in how the channels are named. Some are camelCase and some are not.

For consistency we will have to choose one of the two (camelCase or lowercase). See below.

But I'm happy to change the new channels to camelCase if that's the recommendation. Just let me know.

Yes, that's the recommendation. And since it's already in use for some of the channels, this would be the preferred way going forward. See also https://community.openhab.org/t/naming-convention-for-channels/128841/10.

Had all the existing channel been lowercased (or underscore_separated or dash-separated), the situation would be different. Here I would recommend to prioritize consistency higher than the current recommendation.

[jlaur]

LGTM