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
- Replies:
- Re: Channel Access Protocol Specification Hoff, Lawrence
- Re: Channel Access Protocol Specification Benjamin Franksen
- References:
- Channel Access Protocol Specification Benjamin Franksen
- Navigate by Date:
- Prev:
Re: Channel Access Protocol Specification Benjamin Franksen
- Next:
Re: Channel Access Protocol Specification Hoff, Lawrence
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
<2004>
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Channel Access Protocol Specification Benjamin Franksen
- Next:
Re: Channel Access Protocol Specification Hoff, Lawrence
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
<2004>
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|