Experimental Physics and
Industrial Control System

Steven Hunt <[email protected]> · Wed, 03 Nov 2004 18:13:39 +0100

This is something that people have wanted for a very long time - and
rather than (as usual) talking - something has now been done about it. I
think Cosylab have made a very good start (with of course a lot of input
and help from Jeff). They should be congratulated for this. Of course it
is work in progress, but it has already proved useful in enabling a
wider audience to understand many aspects of the protocol rather than
have to RTFSC.

I seem to remember the epics rule that anyone with a bright idea should
implement it.

Sounds like you a volunteering to help or perhaps even fund this effort?
that way you get it done how you like :)

We are lucky in the Epics community not to suffer from 'flame wars' on
tech-talk - I hope we keep it that way.

Cheers
Steve

On Wed, 2004-11-03 at 12:40, Benjamin Franksen wrote:
> 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