Re: CA protocol documentation.

[Tim Mooney <mooney@aps.anl.gov>]

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