Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 3 Nov 2004 12:40:47 +0100

I noticed a link from the main EPICS web site 
(http://www.aps.anl.gov/epics/docs/ca.php) to a document at Cosylab labeled 
"Channel Access Protocol 
Specification" (http://epics.cosylab.com/cosyjava/JCA-Common/Documentation/CAproto.html).

Unfortunately, this document does not live up to what title and fancy 
presentation promise. It almost raises more questions than it answers. Not 
only is it incomplete and written in a sloppy style, it is also in several 
places ambigous or imprecise, and sometimes plainly self-contradicting. Many 
difficult issues are side-stepped or only hinted at with obscure remarks that 
clarify nothing to someone who doesn't already know what is going on.

Furthermore, it fails to cleary separate core protocol specification from 
side-issues such as recommendations to library designers and suggestions for 
implemention. I am tempted to support these claims with concrete examples 
from the spec, but I fear this would lead to a discussion of technical 
details and therefore divert from the main point I wish to make, which is to 
make a number of meta-suggestions on how to proceed:

1) First and most important: Revert the state of the specification from 
"release" to "first draft" and add some sort of disclaimer to it, stating 
that this is work in progress and not to be relied upon, until it has been 
*thoroughly* reviewed.

2) Make this reviewing process public, inviting and encouraging questions and 
comments, and openly announcing changes and intermediate versions. I think a 
separate mailing list would be appropriate for discussing technical details 
and only summaries and announcements of new version should be sent to 
tech-talk. This approach has proven a good way to produce high quality 
specifications, as witnessed by the standard internet protocols known as 
RFCs, which brings me to the next point.

3) Search for technicaly related RFCs and use them as a template. BTW, RFCs 
are deliberately void of any formatting, favouring content, exchangability 
and system-independence over fancy appearance.

I think this issue is of highest importance to the EPICS community. Every 
expert on EPICS I have talked with agrees that maintaining a high degree of 
interoperability on the CA level even between major EPICS releases is one of 
the reasons why EPICS has been so successful. Since obviously a decision has 
now been made to lay open the CA specification, this means that from now on 
clients and servers may (and ultimately *will*) be written either directly on 
top of the network layer, or using competing libraries (e.g. for use with 
languages other than C/C++), thus bypassing the standard C/C++ libraries 
provided with the EPICS base. If we want to remain confident that such 
applications reliably interoperate with existing and future systems, we need 
an extremely high quality specification.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System