On Monday 17 October 2005 20:14, Kay-Uwe Kasemir wrote:
> On Oct 17, 2005, at 13:41 , Steve Lewis wrote:
> >> 1) EPICS has a narrow interface and ALAMA/ACS has a wide
> >> interface. Narrow means that EPICS just has well defined data
> >> types and wide means that ACS has object to object communication.
> >
> > This is the key difference. The NIF control system also has an
> > ALMA_like, wide, object-to-object interface. My opinion is that
> > this nearly killed it. A wide interface is a very subtle way of
> > replacing the benefits of encapsulation and data hiding with
> > (larger) problem of "interface coupling".
> >
> > You cannot effectively build tools; programmers need to be involved
> > at every level, forever. Even small changes require rebuilding
> > everything: it's "make clean; make" every night--hopefully you have
> > a full suite of regression tests with a lab filled with real
> > hardware. NIF has about $500K sunk in such a lab, and keeps its
> > test team staffed at 25% of the level of the developers.
>
> I believe that. On the other hand this talk listed by Marty:
> http://almasw.hq.eso.org/almasw/pub/ACS/ACSWorkshop2005/
> beyondMiddleware.pdf
> .. which gives the example of replacing CORBA with ICE.
> Now: hard, requires recompile etc.
> Future: easy based on divine framework with interfaces to services in
> containers.
> Can replace the CORBA plugin with an ICE plugin, at run-time, going
> forth and back.
>
> So who's right?
Note that the talk you mention is mostly about the "future", IOW it's
vapor-ware (like EPICS V4 at the moment, to be fair). It all sounds a
bit too optimistic in favour of co-existence of quite different
approaches, IMHO. Look at the internet and how (and why) it took off: a
very small number of rather simple protocols, each dedicated to solve a
dedicated problem; evolution eradicated all competitors to TCP/UDP/IP
as the foundation layer; most commonly used higher level protocols dead
simple (text and even line based), witness http, email, etc.
As Marty observed, it is easy to talk to EPICS/CA. This is because it is
flat, low-level, simple and efficient.
Maybe the direction to go with EPICS V4 is to strive for a two-layered
middle-ware: a low-level part, that will hopefully be even simpler
(conceptually at least) than the current CA, but OTOH flexible enough
to make it suitable as a foundation layer for more specialized
protocols that build upon it. Getting rid of arbitrary size limits and
of a fixed number of data structures and event types are the most
important points here, I'd say. Maybe basic support for crossing
network boundaries. Oh, I forgot a precise specification of the
protocol, independent of any implementation.
We should take care that higher-level stuff such as name services,
support for redundancy, device-priented abstractions, etc. /can/ be
built on top of this, without compromising efficiency or
interoperability, but I think it would be a mistake to try to include
all these things into CA proper.
The decisive advantage of such a two-(or rather multi-)layered approach
is that in case a higher level fails to provide enough flexibility (see
Steve Lewis' sniding remarks ;) there is always the next lower level to
fall back to. In an ideal world, I imagine standard high-level
communication services to be appear as factored-out solutions to common
problems.
[Note: I wrote this before reading the Claude Saunders' post. He argues
in a similar way and I agree with most of it.]
Ben
- References:
- ICALEPCS and EPICS iocCore V4 Marty Kraimer
- Re: ICALEPCS and EPICS iocCore V4 Steve Lewis
- Re: ICALEPCS and EPICS iocCore V4 Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
loosely coupled event systems Jeff Hill
- Next:
Re: [Fwd: Re: Link arrays / syntax] Marty Kraimer
- Index:
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: ICALEPCS and EPICS iocCore V4 Steve Lewis
- Next:
Re: ICALEPCS and EPICS iocCore V4 Claude Saunders
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|