Tango Command full object name

# 6 years ago
Fałek	Hi Everyone, I'm wondering if there is something like full object name for commands. I mean something like this: https://tango-controls.readthedocs.io/en/latest/development/general-guidelines/naming.html?highlight=address%20attribute If there is not, would it be reasonable and possible to have such name? E.g: my/device/1:myCommand(parameters). Mike

# 6 years ago
Reynald	Hi, I don't know in which programming language you intend to program. Usually, to execute a command, you need a DeviceProxy object. When you create the Device Proxy object, you can give a fully qualified device name as parameter to the Device Proxy constructor. Does this answer your question? If not, could you please give more details on what you would like to achieve? Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 6 years ago

Reynald

Hi,

I don't know in which programming language you intend to program.
Usually, to execute a command, you need a DeviceProxy object.
When you create the Device Proxy object, you can give a fully qualified device name as parameter to the Device Proxy constructor.

Does this answer your question?
If not, could you please give more details on what you would like to achieve?

Kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 6 years ago
Andy	Hi Mike, this is a good question because we have not thought about this yet! It would make sense to have a naming convention for Commands like we have one for Attributes. I wonder if we need to distinguish between the fact that it is a command or attribute? We have at least 2 cases where there is a naming convention for Commands : (1) Python - the Python api this has solved elegantly by adding parentheses to the command names e.g. mydevice.mycommand() (2) REST - the REST api has solved this by adding the keyword command as a field e.g. PUT tango/rest/rc4/hosts/tango_host/10000/devices/sys/tg_test/1/commands/DevDouble?v=3.14 The proposal should take into account where this naming will be used. For example if we want the names to be compatible with url's or file names it might not be a good idea to have a colon in the name. Some other proposals could be my/device/1/mycommand(inarg, outarg) or my/device/1/cmd.mycommand.inarg and my/device/1/cmd.mycommand.outarg. All depends how this will be used or if it is only for use in documentation. Cheers Andy

# 6 years ago

Andy

Hi Mike,

this is a good question because we have not thought about this yet! It would make sense to have a naming convention for Commands like we have one for Attributes. I wonder if we need to distinguish between the fact that it is a command or attribute? We have at least 2 cases where there is a naming convention for Commands :

(1) Python - the Python api this has solved elegantly by adding parentheses to the command names e.g. mydevice.mycommand()

(2) REST - the REST api has solved this by adding the keyword command as a field e.g. PUT tango/rest/rc4/hosts/tango_host/10000/devices/sys/tg_test/1/commands/DevDouble?v=3.14

The proposal should take into account where this naming will be used. For example if we want the names to be compatible with url's or file names it might not be a good idea to have a colon in the name.

Some other proposals could be my/device/1/mycommand(inarg, outarg) or my/device/1/cmd.mycommand.inarg and my/device/1/cmd.mycommand.outarg. All depends how this will be used or if it is only for use in documentation.

Cheers

Andy

# 6 years ago
Carlos	Hi, In Taurus we have been thinking about this for some time. We are interested in a way of naming commands (not only Tango commands, but also in other sources of data). Here are some considerations: - in tango attributes and commands may have the same name (e.g. the TangoTest Device implements the "State" command and the "State" attribute), so the "full name" should be different for commands and attributes. The solution of using parenthesis as in tango://host:1234/a/b/c/mycommand() seems reasonable to me. - using a solution such as my/device/1/cmd.mycommand is IMHO not good because it would collide with attributes whose name starts with "cmd." (i.e. it would make cmd.* reserved and this is potentially backwards-incompatible). A better alternative would be to use some other reserved character such as my/device/1/@mycommand - whatever the syntax for referring the command itself, one should also consider whether supporting the reference to command arguments in the URI, and if so, which syntax to use. In the case of Tango, it seems natural to just use the same rules as jive uses when parsing its argin value field - In taurus, since we are python-centric and our model names are URI-based, it would be natural to just use "device URI fragments" to refer to commands. i.e., a full name for a tango command could be referred as tango://host:1234/a/b/c#mycommand This would also make a sense for those data sources such as tango in which you would need the device object anyway to execute the command (i.e. in which a command is indeed a fragment of the device object)

# 6 years ago

Carlos

Hi,
In Taurus we have been thinking about this for some time. We are interested in a way of naming commands (not only Tango commands, but also in other sources of data).

Here are some considerations:

- in tango attributes and commands may have the same name (e.g. the TangoTest Device implements the "State" command and the "State" attribute), so the "full name" should be different for commands and attributes. The solution of using parenthesis as in tango://host:1234/a/b/c/mycommand() seems reasonable to me.

- using a solution such as my/device/1/cmd.mycommand is IMHO not good because it would collide with attributes whose name starts with "cmd." (i.e. it would make cmd.* reserved and this is potentially backwards-incompatible). A better alternative would be to use some other reserved character such as my/device/1/@mycommand

- whatever the syntax for referring the command itself, one should also consider whether supporting the reference to command arguments in the URI, and if so, which syntax to use. In the case of Tango, it seems natural to just use the same rules as jive uses when parsing its argin value field

- In taurus, since we are python-centric and our model names are URI-based, it would be natural to just use "device URI fragments" to refer to commands. i.e., a full name for a tango command could be referred as tango://host:1234/a/b/c#mycommand
This would also make a sense for those data sources such as tango in which you would need the device object anyway to execute the command (i.e. in which a command is indeed a fragment of the device object)

# 6 years ago
Fałek	Hello Everyone, I would distinguish attributes and command, because commands can do complicated staff so it's better to see whether it's an attribute or a command. Moreover the attributes have properties so my/device/1/myCommand->property would be incompatible. Basically I was thinking about Python, JS and SVG (XML based) files but parsing shouldn't be a problem. My concerns were rather about standard way (so documentation purposes are most important think here, I guess) and to not create my own representation. But solution fitting all purposes or at least most cases would be great. Parenthesis seems very friendly to me, because I associate commands with functions. But I'm not sure how it would work for URLs, etc. Some characters are already reserved: :, #, /, ->, but we can use similar ones or in a different way. E.g my/device/1.mycommand(args) or my/device/1.mycommand->args instead of my/device/1/cmd.mycommand.args. Mike

# 6 years ago

Fałek

Hello Everyone,

I would distinguish attributes and command, because commands can do complicated staff so it's better to see whether it's an attribute or a command. Moreover the attributes have properties so my/device/1/myCommand->property would be incompatible.

Basically I was thinking about Python, JS and SVG (XML based) files but parsing shouldn't be a problem. My concerns were rather about standard way (so documentation purposes are most important think here, I guess) and to not create my own representation. But solution fitting all purposes or at least most cases would be great.

Parenthesis seems very friendly to me, because I associate commands with functions. But I'm not sure how it would work for URLs, etc.

Some characters are already reserved: :, #, /, ->, but we can use similar ones or in a different way.
E.g my/device/1.mycommand(args) or my/device/1.mycommand->args instead of my/device/1/cmd.mycommand.args.

Mike

# 6 years ago
Ingvord	IMHO, all Tango entities (hosts, devices, attributes, commands, properties etc) must be URI compatible. So I would suggest to stick with the REST variant. In this case it also good to think about, for instance, device as a meta container for attributes, commands etc from a high level perspective, while on a low level attribute will be independent data point Cheers,