> 1. Parsing the file upon process invocation (e.g, Solaris <=2.4)
>     Pros:	- easy to edit config file.
>     Cons:	- need to restart daemons so that changes are picked up.
> 		- if a process starts parsing whilst an editor is writing
> 		  out the file, it could read a partial config file.

> 4. Reading a pre-parsed database on each lookup (e.g, my implementation)
>     Pros:	- fastest lookup method
> 		- atomic update (via rename of temp file) of database
> 		  prevents race condition of other methods
> 		- all processes pick up changes to methods when
> 		  database is updated - no need to restart
>     Cons:	- requires user to run 'ns_mkdb' when update is made.
> 		  (which does, however, provide the atomicity
> 		   described above)

I've mentioned this to Luke before, but since he's asking for opinions
I'll take this opportunity to make my position known to all.

I'm in favor of implementation 1, but I'm open to the idea of changing
to something *like* 4 if it turns out that parsing nsswitch.conf is
too slow.  I believe it would be easy to make the transition from a
text file to a binary file, as nsswitch.conf would still be available
for old staticly linked executables.  But changing the format or
removing all support of nsswitch.db is a much more difficult
proposition.

I have doubts that reading the database on each lookup is desireable
and whether it will actually be faster than parsing nsswitch.conf at
the time of the first lookup.  Programs that do a lot of db lookups
(ls -l, etc.) could be substantially slowed as each db lookup follows
a nsswitch.db lookup.  And I don't know how well programs would do if
database access methods are changed between lookups.  I worry that the
state of internal datastructures in the db lookup code could become
corrupt.

	--jtc