/*
* Copyright (c) 1996,1999 by Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS
* ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
* CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
* DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
* PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
* ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
* SOFTWARE.
*/
This is the Information Retrieval Service (IRS).
Designed by Paul Vixie (ISC) and Ted T'so (MIT), 1995.
Written by Paul Vixie, Ted T'so and Sam Stoller, 1996.
$Id: README,v 1.5 1999/01/08 19:23:52 vixie Exp $
Introduction:
The /etc/irs.conf file defines access methods (like DNS or NIS or
LOCAL) for each map (like PASSWD or GROUP or HOSTS). One of the access
methods is "generic" in that it uses the rules from /etc/irs.conf to decide
which of potentially several different access methods to use for any given
map. Stubs have been written for all of the system getXbyY() functions so
that old programs can get this new "multiple access method" capability without
any source code changes.
Thread Safety:
It is possible for a thread safe program to be altered to call the
underlying interface (rather than the standard getXbyY() stubs) and get some
reentrance capabilities. Note that the underlying libraries (which we call)
are not all thread-safe, for example, the YP and DNS resolvers. A lot more
work will need to be done before we have full thread safety. But we believe
that the native API for this system does not impose any reentrancy problems.
We don't use global or static variables anywhere except in the getXbyY() stubs.
Apologies:
We did cheap object orientation without using C++. This stuff is
standard C, and it suffers from some of the defects shared by all object
systems implemented in C. Even so, this is the smallest design we could
think of that would be extensible to more access methods, more map types,
and more map operations (like BYNAME or BYGID or whatever) in the future.
There's a fair amount of duplicated code between the different
access methods for a given map. For example, the code that parses the
passwd entries is almost identical between the DNS and NIS map objects. To
clean this up, the almost-identical functions need to be split into similar
and dissimilar parts, and some parts of the "struct pvt"'s need to be made
shared via substructures.
