EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  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  Index 1994  1995  <19961997  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 
<== Date ==> <== Thread ==>

Subject: Re: CA connection
From: Jeff Hill <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Thu, 12 Sep 1996 10:42:29 -0600
Chip,

> If I knew the IOC on which all of my channels were to be found, are there
> any routines for avoiding the broadcast for name resolution?  I.e., can
> I skip the first (broadcast) step and go strait to the connect step?

The answer is unfortunately at this time no.

This request is of course the natural result of evolution towards a
stand alone replaceable name resolution component. Perhaps this should be
done in a slightly different way than suggested above. Perhaps there should 
be an API which CA uses to monitor the location of channel (instead of being 
supplied with this information only once during initialization). That way when 
the channel moves to a different IOC CA will always be able to find it
(in order to remain compatible with past CA functionality).

Here is a hack at an API for a resource locator object:

class resourceLocationMonitor {
	resourceLocationMonitor(resourceLocator &, const resourceIdentifier &);
	~resourceLocationMonitor();
	virtual locationCallBack(class locationInfo &);
};

The location call back would be called when the location is
discovered for the first time and whenever it changes.
I suspect that the resourceIdentifier class would have support
for at least ASCII resource identifiers and wildcard pattern matching.
We would also need to support independent resource name spaces.


> 
> If the answer is no, how difficult would that be to add?

This is mostly an issue of reorganizing the code I think. 
Nevertheless, I will avoid making any estimate of the effort
required until we are further along with the design.


Jeff

-- 

______________________________________________________________________
Jeffrey O. Hill			Internet	[email protected]
LANL MS H820			Voice		505 665 1831
Los Alamos, NM 87545 USA 	FAX		505 665 5107


Navigate by Date:
Prev: Re: dm colour rules with -ve values Deb Kerstiens
Next: Re: A tool to support development of GP-IB device support routine. Noboru Yamamoto
Index: 1994  1995  <19961997  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: dm colour rules with -ve values Deb Kerstiens
Next: Re: Hideos Mark S. Engbretson
Index: 1994  1995  <19961997  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 
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 ·