Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 14 Nov 2002 11:08:00 -0700

All,

It's true that there is no formal documentation for the Channel Access
protocol as it exists today. Ralph already mentions several good reasons
why we need to be careful so please forgive my own slant on some similar
ideas.

I feel that a well documented protocol is a good idea for an open system
such as EPICS. This would allow for alternate implementations of the
core system libraries that pump protocol elements on and off of the
wire. Alternate implementations would allow for competition and
ultimately better software. However, while I think that many of us have
high aspirations for EPICS, we must also be realistic about size of the
EPICS community today and what is possible with the limited developer
resources that are currently available. In a system such as EPICS we
don't want competing versions which are subtly different in their
interfaces to other parts of the system, are not supporting all
available features, or are not implemented to a high level of quality. A
fundamental problem is how we get from where the Channel Access protocol
is today to where we want it to be in the future. If the current
protocol is documented and alternative libraries are written this might
be occurring with unfortunate timing because it is just now that we are
about to embark on significant changes to allow more flexibility about
how application programs can extend and manage the packaging of data
that is passed over the wire. The bottom line is that a protocol
document should be the necessary end product of designing and reviewing
the next generation of the protocol. Once we have a solid foundation in
place then it will be more rational to consider the merits of allocating
additional resource to develop competing protocol dispatch libraries
when there is a realistic opportunity for interoperability and
competition between competing approaches.

The perils associated with this issue bring to mind the situation with
operator interface programs and EPICS today. We have many different
competing programs with very similar feature sets. That by itself is not
a problem, but when you consider that there is limited interoperability
between these programs at a display list level, and that therefore they
cannot truly compete with each other, then the additional resource to
develop all of these programs is harder to justify from a purely
practical perspective. Given that many of these programs, at least when
they were initially written, were able to interpret the display list
file protocol of one of the other popular OPI programs, then it seems
that small differences in the structuring of software interfaces, and
small differences in the ways that a group such as EPICS collectively
extends them, can lead to fundamental differences in the efficient use
of software development resources.

Jeff

> -----Original Message-----
> From: Noboru Yamamoto [mailto:[email protected]]
> Sent: Wednesday, November 13, 2002 6:27 PM
> To: EPICS (E-mail)
> Subject: CA protocol documentation.
> 
> Hi,
> 
>  There is a guy who wants know the detail of Channel Access
> protocol.
> Is there any CA protocl documentation other than C source code
> itself?
> Or any pla to write the document of CA protocol?
> 
> Noboru Yamamoto
> EPICS group/KEKB control Group
> KEK, JAPAN

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System