Discussion: Move OPIs to server

[DominicOram]

As a developer I might like to move OPIs to the server and get them remotely from the GUI. This has the advantage that the OPI and IOC will be next to each other and so kept up to date together. We briefly discussed this in #6131 but had some concerns about:

• What mechanism we would use to transmit the OPIs between client and server
• How we would deal with OPIs that communicate with multiple IOCs

Acceptance Criteria

• Look into mechanisms CSS has for looking at remote OPIs
• Discuss whether we want to do this

[FreddieAkeroyd]

According to http://cs-studio.sourceforge.net/docbook/ch15.html "The files could be in a network file system location, but since the detailed path name syntax for such shared file system location often differs between operating systems, a web location might be more practical. BOY can read files from http://, https:// and ftp:// URLs." It was unclear if this just meant font etc. files but later on the page it says "The default for the Top OPIs will point to the BOY example files like /BOY Examples/main.opi. You probably want to adjust them to load certain top-level OPI files of your site, like http://my_opi_server/opis/start_screen.opi" which suggests OPIs could all be loaded via the web

[ThomasLohnert]

From discussion on 16/03/22 (Attendees: Darya, David, Freddie, Jack A, Kathryn, Sam, Thomas):

Suggested solution

Each OPI lives in its submodule, but gets built into a separate, central build area (which may also need to be a repo)

Advantages:

• Cleaner separation between client and server
• Less need for switching environment mid-development, e.g. looking at remote machine gives you OPI that goes with their version of the IOC
• Less repos touched when modifying device driver, simplifies workflows
• Everything you need to potentially run a device is in one place (makes sharing drivers easier, too)
• Central repo can house OPIs that don't neatly relate to one IOC (e.g. RIKENFE)
• Client takes up less space (although not significantly)

Disadvantages

• Extra build step

Suggested implementation

Do this in several stages to minimise disruption:

0. Check remote access of OPIs works fine for a single OPI before converting everything, i.e. check that CSS lets us do this, check there is no significant performance loss
1. Move OPI repository out of client (but still mirror it into the usual folder in the client)
2. Remove OPIs from client and make it get them from the server via web instead
3. Move each OPI into its related support modules & copy into central repo via build script

[ThomasLohnert]

We have a githook on the ibex_gui repo which adds a dummy button to each OPI as a hack to ensure the autofocus after entering a value does not jump to anything dangerous. We need to think about how best to retain this check after moving the OPIs to individual support modules

[KathrynBaker]

I have created tickets #7088, #7089. #7090, #7091 and #7093 to cover this work when the time comes. Closing without adding to the sprint, or seeking a review, as a discussion was had, a plan defined, and an initial path to try.

[FreddieAkeroyd]

even if step 0 is not possible, steps 1, 3 are likely worth doing anyway i.e. we assemble the opi files on the server and publish them for the client to pick up. This still gives us the organisation advantages. Also we just nee to be a bit careful about saying "copy into central repo" - this is not a repo in the git repo sense as we are copy in derived data. We may need a separate repo for opis that don't fit into any neat support area, but we may still publish from there to a non-git repo central area