Experimental Physics and
Industrial Control System

"Ales Pucelj" <[email protected]> · Wed, 3 Nov 2004 13:57:57 +0100

Thanks for taking the time to review the document and the feedback provided.
The document was released with the hope of raising the interest in the EPICS
community about more formal specification of EPICS environment and any
review is greatly appreciated.
CA specification appears to be some sort of holy grail, which would
naturally allow greater proliferation of EPICS implementations, across a
broad range of platforms. As such however, developing a complete and
comprehensive coverage of the protocol requires broad understanding of the
basic design and implementation concepts in current and past EPICS
implementations.
While EPICS team (Jeff Hill in particular) have been very helpful in this
respect, we all realize, there is much more work to be done.

Current version of the document was aimed to provide complete structural
description of protocol as implemented in CA protocol version 4.11, but
still avoiding the current LANL implementation specifics.

While this specification concludes the current requirements and scope, we of
course realize, that much more work is required to meet the expectations of
entire EPICS community. As such we are always open to suggestions on how to
proceed and what else to provide.

A new mailing list would of course be an ideal media for gathering new
comments, revisions, suggestions. In our opinion, the best way would be, to
create a parallel list to TechTalk. List would of course be public and
everyone here would be invited to contribute.

- Benjamin, please send the detailed comments and issues to the list (when
founded), or directly to me and maybe CC: Jeff Hill.

>
> 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

While I absolutely agree with you on this, during the correspondence with
Jeff Hill it quickly became clear, that core protocol and implementation
specific details in case of CA are not independent. A great amount of work
went into current CA implementation, with some scalability and performance
issues evolving over years. It is thus impossible to limit specification to
semantics of the protocol itself.

> 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.

The release refers to the current scope. It does not in any way mean to be a
complete and comprehensive coverage of entire protocol and all the
intermediate versions.

>
> 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.

Choice of presentation has been a great issue, so the content of the
document is stored in presentation independent XML, the HTML version
provided on the page is for convenience only. The sources are of course GPL
licensed and available on request.

>
> 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.

While I agree with you, I need to point out, that the greatest concern
expressed by LANL has been, that opening the specification raises the risks
of partial and quick-and-dirty implementations would severely compromise the
interoperability of EPICS systems. As such, a complete and comprehensive
document, that covers all protocol versions (4.1 - 4.11) would be enormous
and implementation would require for all practical purposes too great an
effort.

Main point of this document should be of course a step towards opening and
formalizing the CA protocol. This has already been achieved with pure Java
implementation of the protocol, which has already been released.

Best regards,
	Ales

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System