EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: CA protocol documentation.
From: Tim Mooney <[email protected]>
To: [email protected]
Date: Thu, 14 Nov 2002 15:03:20 -0600
re...,

>... 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 timing/next-generation argument is a good one, and it's one reason
we
haven't supported attempts several years back to reverse engineer the
protocol, as a way of getting to a pure java implementation, for
example.
But the fact that significant resources /were/ expended--independently,
by
more than one developer--in reverse engineering CA should not escape
notice.
Although pure java would probably have debilitating limitations, it
would
also provide significant benefits for our users, in niche applications.

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

I think the two situations are not comparable, because nobody capable of
collaborating would purposely do what these OPI guys have done.  In the
OPI
area, this is just a lost possibility.  But in the protocol area, the
effort
of someone incapable of collaborating would not produce anything of
value
anyway, so it would be fine and maybe even preferable for such a wheel
to
spin freely.

Tim Mooney

Replies:
RE: CA protocol documentation. Jeff Hill
References:
RE: CA protocol documentation. Jeff Hill

Navigate by Date:
Prev: Re: CA protocol documentation. Chip Watson
Next: RE: CA protocol documentation. Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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: CA protocol documentation. Jeff Hill
Next: RE: CA protocol documentation. Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·