Experimental Physics and
Industrial Control System

Dear Ryan

Many thanks for your earlier comments / questions which I will
try to address below.

Best regards

Simon


1. About PSI CA Library

 > Should we combine / merge / abandon the JCA / CAJ library?
 > Looks like no one is really maintaining the old library
 > and in fact it appears some of the original CAJ developers
 > are working on the newer "ca" library.

One significant difference between the JCA/CAJ and PSI CA
libraries is that the PSI CA library implements only the CA
CLIENT-SIDE functionality. So without significant effort it
cannot play the role of a CA Server. My efforts so far have
been limited to consolidating what exists rather than adding
new things. The initial goal was to eliminate the warnings
emitted by my (IntelliJ) IDE and to bring the build system and
CI integration up-to-date. So far I refactored code mostly
around the CA Repeater and monitor notification engine, writing
many tests to try to reassure myself that the changes did not
(hopefully !) break anything.

Regarding the internal LMAX Disruptor technology, I was never
able to demonstrate measurable test results which proved that
this technology brought significant gains (given the scenario
in which we were using it).  So a configurable, common-or-garden
Java blocking queue implementation was introduced a couple of CA
releases ago, and now, in the latest release, the LMAX Disruptor
was finally retired.

2. About Wica-HTTP

 > There are a lot of these now.  I'll update my list here:
 > https://github.com/JeffersonLab/epics2web/wiki/Similar-Projects
 >
 > A comparison might be useful. One thing that jumps out
 > is that you use Server Side Events (SSE).  These weren't
 > really an option a few years ago due to Internet Explorer
 > not supporting them.   Now that Microsoft Edge uses
 > Chromium under the hood that's no longer an issue.

Thanks for the link to the list, which I wasn't previously aware
of. Of course everything is a trade-off, each technology
bringing with it plusses and minuses, those who love using it
and those who emphatically don't. 'Twas ever thus, I guess.

One aspect of the Wica-HTTP backend that's perhaps worth
mentioning: by basing the server on Java's Spring Boot framework
the intention was to eliminate the need to write lots of code,
but to use the effort saved to write useful tests. Hopefully,
in this respect we have been at least partially successful.

3. About Wica-JS Server

 > Looks like you've got to be web developer to use this
 > library?  Maybe a builder interface like EDM/CSS is in
 > the works?  For example:
 > https://github.com/JeffersonLab/puddysticks
 > <https://github.com/JeffersonLab/puddysticks>
 >       
 > GitHub - JeffersonLab/puddysticks: Control panels made easy
 > <https://github.com/JeffersonLab/puddysticks>
 > Control panels made easy.

Thanks for the links which I will look at. Whilst it's almost
trivial with Wica to create simple HTML pages rendered with live
EPICS data, it's a much harder proposition to create web pages
that work on multiple mobile/tablet/desktop platforms and which
provide the sophistication and (mostly !) pleasant user
experience that the modern web delivers.

 From time to time I have gone looking for some kind of GUI
designer for the web (a la MEDM/EDM/caQtDM) but so far I didn't
find anything that seems to hit the simplicity versus
flexibility sweet-spot. Or at least none that does it in a
technologically-agnostic way.

One technology that we are tracking closely at PSI is the
ongoing evolution of the web components world:
https://en.wikipedia.org/wiki/Web_Components

The WC standard potentially opens up the possibility of
creating GUI tools that do not tie one to committing fully
to a front-end technology that may quickly go out of
fashion. I am still hoping that something may emerge, but
then I have been hoping that for quite some time now !