POETSII / Orchestrator

The Orchestrator is the configuration and run-time management system for POETS platforms.
1 stars 1 forks source link

Populating SupervisorType/Properties #323

Open m8pple opened 1 year ago

m8pple commented 1 year ago

The SupervisorType can define a Properties struct, which can be accessed through supervisorProperties. However, there is no way (I can see) of populating these properties on a per-graph instance basis, as the supervisor does not appear in the edge instance (because it is shared). The only way I can think of to get things into supervisorProperties would be to define a struct with default initialisers, but there would then be no way of changing them.

Trying to think of what it could be used for, the only things I can think of would be effectively graph level properties, which would already be covered by graphProperties, and can then be populated in the graph instance as normal.

Are there any examples of where they are needed?

mvousden commented 1 year ago

The SupervisorType can define a Properties struct, which can be accessed through supervisorProperties. However, there is no way (I can see) of populating these properties on a per-graph instance basis, as the supervisor does not appear in the edge instance (because it is shared). The only way I can think of to get things into supervisorProperties would be to define a struct with default initialisers, but there would then be no way of changing them.

Trying to think of what it could be used for, the only things I can think of would be effectively graph level properties, which would already be covered by graphProperties, and can then be populated in the graph instance as normal.

Are there any examples of where they are needed?

Strictly speaking, supervisor device properties (like normal device properties) do not offer functionality that one can't already achieve with state. They exist purely as an access control mechanism - hence there are no examples of where they are needed. Let's put this to one side, however...

One point where you might want to define a supervisor property over a graph property is if it uses a type that is not easily defined on the level of normal devices - something like: std::vector<std::string> octopuses (4, "octopus");.

A more practical example (which admittedly works around the language we've defined) is in a template xml - let's say you have a template with supervisor property:

# Using the syntax from the simple templating engine at https://github.com/mvousden/ste/
std::vector<std::string> deviceNames = {{v:device_names}}

where the xml generator would define a variable called device_names to be inserted here. This would not work on the level of graph properties for the same reason octopuses wouldn't work, but it can function well as a supervisor property.

...whether I think this is a particularly elegant solution, however, is another matter!

@heliosfa thoughts?