Use of Tango display level

[burkeds]

Tango has the concept of a "Display Level", this is a variable that specifies OPERATOR, or EXPERT. It serves no function in Tango itself, its purpose is as metadata for applications like GUIs that may want to only display certain devices/attributes/commands to certain users.

https://tango-controls.readthedocs.io/en/latest/development/advanced/reference.html#the-attribute-display-level-parameter

Do EPICS PVs have a value which serves a similar role?

The event model does not have an obvious place this variable can live. While it's not important for Bluesky/Ophyd-Async, its presence in the model would allow people to build better applications from the document stream. What do you think @danielballan?

[evvaaaa]

I think we should make a new field

display_level: NotRequired[Optional[int]]

in DataKey.

Then a transport can choose to use it if has meaning. For tango, the value would be the one specified in this enum.

[coretl]

Adding another key sounds fine to me, and the Tango name makes sense to me, but I'd prefer a string or enum to an integer, and to drop the Optional. I'd propose:

display_level = NotRequired[Literal["operator", "expert"]]

@evvaaaa I remember we needed Optional for back compat for precision and units, but I can't think why we would need it for new fields?

[evvaaaa]

I remember we needed Optional for back compat for precision and units, but I can't think why we would need it for new fields?

True, we don't.

I'd propose.

I wanted to leave it as an int in case some control system has different terminology, but I'm happy with either.

[burkeds]

@evvaaaa We discussed this with @danielballan and @tacaswell during the meeting yesterday and I think we're ok to go ahead and add this to the datakey. Someone else in the call seemed like they had a use case for it already. I agree, I think an integer would be better than a literal, its more control system agnostic.

[tacaswell]

If there are enums in Tango, then we should go with the string values rather than the integer.

If we leave it as integers there is a risk of different systems using different enum mappings and we don't have any way for the client to tell which enum mapping to use!

Going with strings avoids that problem and clients that need the integers can do the reverse mapping (and at least be able to tell if they are being provided enums outside of their gammut and do what ever they want about it.

I don't think we want to promote this to be a configuration (which then also gives us a describe configuration where we can record the enums).

[burkeds]

If there are enums in Tango, then we should go with the string values rather than the integer.

If we leave it as integers there is a risk of different systems using different enum mappings and we don't have any way for the client to tell which enum mapping to use!

Going with strings avoids that problem and clients that need the integers can do the reverse mapping (and at least be able to tell if they are being provided enums outside of their gammut and do what ever they want about it.

I don't think we want to promote this to be a configuration (which then also gives us a describe configuration where we can record the enums).

This approach sounds good to me.