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.

[JeanLucPons]

This is the goal of PyaML to standardize all these devices we share.
If i get BPM offsets for instance: some have may data returned by the cs as a single vector [dx0,dy0,dx1,dy1, ...], some other as 2 vector [dx0,dx1,...] [dy0,dy1,...] as others (as at ESRF) by direct access to each BPM, etc...

[gupichon]

Yes, we must distinguish between access to raw data, which may be provided by a catalog such as the yellow pages, and access to higher-level elements such as BPMs.
When a BPM is requested, the corresponding PyAML object is returned. However, the system can also provide facility-specific data when available, including the raw data used by the standardized BPM element.

[JeanLucPons]

Yes, the aim of the catalog is to return DeviceAccess handle, then if you call get() on it, you get raw data.
Nothing prevents to have names in the catalog that are not used in the pyaml core for facility specific data.