/* * 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.