Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 3 Nov 2004 15:41:28 +0100

On Wednesday 03 November 2004 13:57, Ales Pucelj wrote:
> 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.

Then why not say so in the document?

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

That is definitely a good start and I greatly appreciate the efforts you made. 
My judgement would have been a lot less severe had you limited the scope of 
the document accordingly and add a disclaimer that it does not attempt 
resolve issues regarding backward compatbility with older versions.

But even provided you had done so, there still remain a number of ommissions 
and ambiguities in the document which woudl normally forbid labeling it with 
'status release'. As I said before I won't go into details here to prove 
that, so I'll drop the issue.

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

It's not a matter of what else to provide but of fixing the spec because it is 
useless as it stands.

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

Yes. Maybe the clickable Mail-Comments symbols in the document should include 
all the relevant persons as receiver? (Currently it mentiones Jeff only).

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

Rest assured I am completely aware of the situation.

> It is thus impossible to limit specification to 
> semantics of the protocol itself.

If you mean that is is necessary to include timing restrictions I agree. These 
can be formulated without any reference to implementation. What i expect from 
a protocol spec is more than just an enumeration of how the packets are 
structured. The spec must clearly state how the client and server are to 
*behave* without in any way imposing *how* it achieves this behavior.

The behaviour of client and server can and must be described precisely and 
unabigously. It doesn't help in a any way to include comments about what a 
library should offer in its API to user programms. It doesn't matter at all 
if the programm uses a library or if it implements everything on top of raw 
TCP/UDP. What matters is that it behaves correctly.

Recommendations for library writers are useful but belong into a separate 
document or maybe an appendix to the spec.

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

Completeness and correctness are necessary even if one limits the scope to the 
latest version (4.11). Until this is achieved, I recommend labeling it 
"draft".

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

All very nice. But i needed to try four (4) different browsers on 2 operating 
systems until i could print the document with all graphics correctly 
displayed: Linux/KDE Konqueror and Firefox both hung completely and had to be 
killed; Windows: Firefox (latest release) printed but with two graphics 
missing, MS Internet Explorer finally suceeded.

Mark, I don't blame this solely on your document. It is a bad record for the 
Linux tools that they couldn't handle the document properly. OTOH, RFC style 
(maybe simple(!) HTML) would help to attract people to collaborate. Or you 
could provide a printable version (pdf or ps) to download.

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

This is definitely the danger. The document as currently presented imposes 
just such a danger, because

1) too many difficult points are *not* completely specified, and

2) still, the document claims completeness.

If it were labeled as work-in-progress, the danger would be reduced, at least.

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

It is probably not necessary to completely document all 4.x versions. I'm not 
even sure it would be a good idea, even provided we had the resources in 
manpower. What is needed is 

1) a complete and unambigous definition of 4.11 including all the necessary 
timing requirements

2) an appendix to the spec that includes those and only those protocol 
features from older versions that are no longer used in the latest version, 
but which an implementation must be aware of in order to correctly 
interoperate with older clients or servers.

The second part is clearly difficult and probably must remain a rough scetch 
as long as we lack the manpower to do it right. This is not problematic if 
this is clearly stated. As competing implementations appear, the issues can 
be clarified more thoroughly. Also we need discussion about how far to go 
back in compatibility. It would help to have at least a table indicating 
which EPICS base releases use which version of CA.

The first part is something that should be done ASAP.

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

Are you sure you meant what you've written here?

The document is a step towards formalizing and opening CA and with the release 
of the Java implementation this goal has been achieved?

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System