Feedback on accml: Working Group 2 (Jean-Luc, Guillaume, Waheed, Vadim, Ilya)

[gubaidulinvadim]

We've spent one of the two morning sessions looking in detail on accml repository examples. Waheed has shown us SOLEIL-twin-based examples and BESSY-II-twin-examples.

• Configuration layer is done similarly to pyaml (not identical) with .yaml/.json files. This seems to be easily mergeable
• YellowPages but that return objects (separate catalogue of devices) concept is very useful to look through the database and should be implemented for pyAML
• async should not be exposed to the user, but it is good to use it
• Too many folders, some facility-specific part in the core (not nice)
• The User API is too complicated for the moment. Waheed: "The final API can always change from his perspective, and this depends on the user feedback. We mostly care about the design patterns. The API is up to the community to define."
• There are examples with combined function magnets for MAX IV. This will be inspected later.

[TeresiaOlsson]

What about an option where async is per default not exposed for the user but still possible to access and use for advanced users? At HZB we have some advanced users who already has started to discuss some possible things they could do with the async interface. Could it be possible to have both options in some way? I have seen that in pytango this seems to be possible by choosing which green mode to use?

[gupichon]

This is a reasonable request and should be feasible.

[lnadolski]

YellowPages could be extended to get information about facility-specific information, operation mode configuration, and data storage information.

[gupichon]

Yes, in a generic way, you should be able to describe any data you want to access, and the yellow pages can provide the object to read the value when needed, depending on the context (design/sim/live). Some values may not be available in all modes, and this will have to be handled.