Argonne National Laboratory

Experimental Physics and
Industrial Control System

<19941995  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  Index <19941995  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 
<== Date ==> <== Thread ==>

Subject: RE: EPICS dependency
From: Mark D. Anderson <anderson@aries.sbc.anl.gov>
Date: Thu, 8 Sep 94 11:50:55 CDT
RE: "I suggest that tools which are intended to be an intrisic part of EPICS
... not be dependent on third party software" -

This is an issue that is not so easily handled or dismissed.  It is a valid
goal to have EPICS be portable, and attempts are being made to do that,
even in the selection of 3rd party software.  (I won't belabor the
tie to VxWorks here, but this discussion certainly could include that
topic as well!)

For most software development for projects with finite resources and
time constraints (and that covers every project these days), the fundamental
parameters being optimized in general are cost, and time to deployment,
with attention being paid to portability.

Deciding to spend $2K on a 3rd party software package or spending 6 man-months
to multiple man-years of development effort is usually not a hard decision
to make.  In the selection of the two packages in question (XRT/Graph
and QuestWindows), portability, platform availability, cost, run-time costs,
et cetera, were all considered prior to adoption.  Both packages scored
high on these metrics, were stable, and cost-effective solutions to
problems being addressed.

Noting especially that both packages have no run-time fees for binaries
generated (cost is on development, not deployment), I frequently wonder
why everyone insists on building all their own EPICS tools anyway.
Apart from Motif licensing (run-time licensing) which is currently included
gratis in all systems in use save for SUN, there would be no encumbrances
to a binary distribution model for EPICS...

When that mechanism fails, there is still recourse for those who don't
want to purchase a product for builds/development: offer equivalent
functionality (and possibly APIs) to the package in question, then either
link against the replacement package, or lobby for compile-time 
modifications to the software to accomodate a new package where
possible.  For example, MEDM could simply have the Cartesian Plots turned
off, and XRT/Graph would not be necessary.  Or someone could write a
graph widget, possibly following the XRT/Graph APIs...  But I'd be willing
to bet money that no one raises their hand for that, unless they've got a
bundle of money and programmers that they are keeping a big secret.

Please understand that I am not belittling your comment in any way, I am
merely pointing out the economic and pragmatic factors which influence such
decisions.  As we move from a project-centric development model (with APS
being the dominant project which has offered its develoment efforts to the
collaboration) to a collaboration-centric development model, such development
decisions as 3rd party software packages will need to be discussed at the
collaboration level.


	- Mark Anderson


Navigate by Date:
Prev: EPICS dependency Edmond Desmond
Next: R3.12 at CEBAF !? mcgehee
Index: <19941995  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 
Navigate by Thread:
Prev: EPICS dependency Edmond Desmond
Next: R3.12 at CEBAF !? mcgehee
Index: <19941995  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 
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 ·