The CSO Nameserver
Why?
December 7, 1989
_b_y _S_t_e_v_e_n _D_o_r_n_e_r
_C_o_m_p_u_t_i_n_g _S_e_r_v_i_c_e_s _O_f_f_i_c_e
_U_n_i_v_e_r_s_i_t_y _o_f _I_l_l_i_n_o_i_s _a_t _U_r_b_a_n_a-_C_h_a_m_p_a_i_g_n
Introduction
There are several documents that describe the function, imple-
mentation, and use of the CSO Nameserver. This paper has a
slightly different thrust; it endeavors to answer the question,
``Why?'' Why did we want a Nameserver? Why did we put in the
features we did, and not others? Why did we develop our own
rather than use someone else's? Why did we choose the CSNET
server as a starting point, and what are the differences between
our Nameserver and the CSNET server?
This paper should be of most use to those contemplating a name
service for their own organization. We hope it will at least
point such people at some of the questions to ask about a name
service; we do not pretend that they will reach the same conclu-
sions as we did.
Necessary to the understanding of this paper is _T_h_e _C_S_O
_N_a_m_e_s_e_r_v_e_r, _A _D_e_s_c_r_i_p_t_i_o_n. _A _D_e_s_c_r_i_p_t_i_o_n explains exactly what
our Nameserver is, and how it operates. We will assume that the
reader is familiar with that information, and will not attempt
here to duplicate the explanations offered in _A _D_e_s_c_r_i_p_t_i_o_n.
The CSO Nameserver is, like many systems, the product of
design, accident, and evolution. Not everything panned out as we
had hoped; some things we thought were important were eventually
discarded; some things we tried did not succeed. Special note
will be made where the reality differs radically from the inten-
tion. These places merit close scrutiny, since they indicate a
place where the ``right'' choice is probably not very clear.
Why Have a Name Service?
The first question to be answered is, why do this thing at all?
What are the real benefits of a name service like the CSO
Nameserver? We had several reasons for expending the effort to
create our Nameserver.
o+ Electronic mail directory. First and foremost, we want-
ed some way for people in our University to find one
another's
electronic mail addresses. There are hundreds of com-
puters in many different departments, and finding
somebody's email address was like looking for a needle
in a haystack. A name service would provide a central
collection and inquiry point for electronic mail ad-
dresses. We have found the Nameserver to be very useful
in this regard, although it has been difficult to col-
lect the electronic mail addresses.
o+ Automatic mail forwarding. Another reason, ironically,
that we wanted a Nameserver was to eliminate the need
for explicit electronic mail addresses. A central repo-
sitory of specific email addresses would give us the ca-
pability to accept very general addresses, such as
``Steve.Dorner@uiuc.edu,'' turn them into proper elec-
tronic mail addresses, and deliver them. This would not
only eliminate the need for correspondents to know email
addresses, but would also allow people to move from
machine to machine without having to retrain everyone
who sends them mail. It would only be necessary to
change the electronic mail address in the name service
to change the account that receives a person's mail. In
practice, we have found this to be a very convenient
service.
o+ Electronic ``Phone Book.'' Another function of a name
service would be as a replacement for the paper phone
book. It could be used to look up mailing addresses and
phone numbers of people or campus organizations, just
like a regular phone book. Unlike a regular phone book,
it would be ready at the fingertips of anyone on our
campus network, not across the room on a bookshelf.
Also unlike a regular phone book, it could be kept up to
date as people move around in the University. We are a
little suprised that this is the big hit of our
Nameserver, and the major reason that people use it.
o+ User validation. Given a name service that keeps some
information about everyone on campus, it is reasonable
to contemplate using it as a central point for authenti-
cation. A user would identify himself to the name
server, and other systems would accept the name server's
word that the user was who he said he was, eliminating
the burden on the user of remembering many different
passwords, as well as ensuring security. This was not
to be part of our initial implementation, however.
[_R_e_a_l_i_t_y: _W_e'_v_e _l_a_i_d _t_h_i_s _i_d_e_a _a_s_i_d_e, _a_s _M_I_T'_sKerberros
_a_d_d_r_e_s_s_e_s _t_h_i_s _i_s_s_u_e.]
o+ Accounting. The name service could serve as a central
repository for accounting information. We considered
this to be a rather marginal benefit, and have found no
particular
reason to go further with it.
What is has come down to for us is: the Nameserver is a very
good substitute for the paper phone book, a substitute that peo-
ple really like; the Nameserver is the only way to find out
someone's email address; and the Nameserver is very useful for
forwarding mail.
What Did We Want In a Nameserver, and Why Did We Want It?
We had definite ideas about some of the features we wanted in
our name service. The following items were considered essential:
o+ Flexibility. We wanted our name service to be a fairly
general tool. Rather than try to think of all possible
uses of it beforehand, our goal was to come up with a
design that would give us the freedom to add new data
items or new categories of entries. The keeping of
tagged fields and the use of field properties in our
Nameserver have met this goal completely.
o+ Large Capacity. Obviously, we needed a database that
could handle the fifty to one hundred thousand entries
we were expecting. This is actually a rather magic
range; in the middle of the range, one exceeds the capa-
city of 16 bit pointers. Our Nameserver uses 32 bit
pointers, and so is quite safe from a size standpoint.
o+ High Performance. The system has to be very fast if it
is going to be used; no one is going to want to wait a
long time to look up a phone number. Moreover, low de-
lay is absolutely essential if a name service is going
to be involved in mail handling. Response time for our
Nameserver on a typical query is 1 second, and most of
that is spent on network setup, so we are pleased with
performance.
o+ Online Update by Users. We wanted a name service in
which individuals could update their own information.
There were basically three reasons for this; two practi-
cal and one philosophical. The practical reasons are
that we didn't want to bear the large clerical burden of
keeping the database up-to-date, and we didn't want to
incur the inevitable time and accuracy penalty that goes
with the aforesaid clerical burden. The philosophical
reason is we'd rather users have control of their own
information, unless there was a good reason for them not
to do so. We allow anyone to change most information
about themselves in our Nameserver; they can do it any
time they wish, and the changes are instantly available
to others.
o+ Network-based. Obviously, a large database that is be-
ing dynamically updated is going to have to be accessed
over a network. Even if the database wasn't too large
to
be replicated on each computer, the fact that updates
are possible at any time would mean the databases would
be out of date immediately. A distributed system such
as that used by the Internet Domain Name Server could
have been used; both implementation restraints and secu-
rity concerns made us decide in favor of a single, cen-
tralized database.
We feel that our Nameserver has met all of the essential re-
quirements listed above. We also had a list of items that would
be nice, but were not considered essential, for a name service.
Our track record with these items is less good; some of them were
not done because we changed our minds about their worth, others
because we just didn't have the time to implement them.
o+ The Owning Account. This idea came from the CSNET Name
Server; the gist of it is that each user has a single
account which ``owns'' his or her entry. The name ser-
vice only requires that the host on which the account
resides verify that the account accessing the entry is
indeed what it is claimed to be; no passwords are re-
quired of the user. [_R_e_a_l_i_t_y: _W_e _n_e_v_e_r _d_i_d _t_h_i_s. _I_t
_r_e_q_u_i_r_e_s _t_h_a_t _t_h_e _h_o_s_t_s _o_n _w_h_i_c_h _o_w_n_i_n_g _a_c_c_o_u_n_t_s _r_e_s_i_d_e
_h_a_v_e _a _h_i_g_h _d_e_g_r_e_e _o_f _c_o_o_p_e_r_a_t_i_o_n _w_i_t_h _t_h_e _n_a_m_e _s_e_r_v_i_c_e,
_s_o_m_e_t_h_i_n_g _w_e _d_i_d _n_o_t _f_e_e_l _w_e _c_o_u_l_d _g_e_t _f_r_o_m _a_l_l _t_h_e
_U_n_i_v_e_r_s_i_t_y _c_o_m_p_u_t_e_r_s. _W_e _c_o_u_l_d _d_o _t_h_i_s _f_o_r _t_h_o_s_e _w_e _a_d_-
_m_i_n_i_s_t_e_r _o_u_r_s_e_l_v_e_s, _b_u_t _h_a_v_e _n_o_t _f_e_l_t _a _g_r_e_a_t _n_e_e_d _t_o _d_o
_s_o. _I_n_s_t_e_a_d, _w_e _a_s_s_i_g_n _p_a_s_s_w_o_r_d_s _t_o _a_n_y_o_n_e _w_h_o _w_i_s_h_e_s
_t_o _c_h_a_n_g_e _h_i_s _o_r _h_e_r _i_n_f_o_r_m_a_t_i_o_n.]
o+ Domain-based Authorization. Along with the concept of
the owning account came the idea of domain-based author-
ization. In short, one viewed the owning account as be-
ing composed of several domains, each of which would
have its own Nameserver entry. Further, each of these
domains would be allowed to do updates on the informa-
tion kept about anyone whose owning account was in its
domain. For example, if the owning account for my entry
was ``dorner@garcon.cso.uiuc.edu,'' there would be five
``people'' who could update my entry:
dorner@garcon.cso.uiuc.edu (me)
garcon.cso.uiuc.edu (my system administrator)
cso.uiuc.edu (my department)
uiuc.edu (my University)
edu (the super-user)
This would allow us to restrict some fields in our name
service to being changed at certain levels; for example,
only my department (or above) could change my job title.
This would maintain the integrity of the database (I
couldn't lie about myself), and at the same time would
not place the burden of upkeep on any single area; each
domain would handle its own. [_R_e_a_l_i_t_y: _W_e _n_e_v_e_r _i_m_p_l_e_-
_m_e_n_t_e_d _t_h_i_s _s_c_h_e_m_e. _M_o_s_t _d_a_t_a _e_l_e_m_e_n_t_s _a_r_e _c_h_a_n_g_e_a_b_l_e
_b_y
_t_h_e _i_n_d_i_v_i_d_u_a_l_s _i_n_v_o_l_v_e_d; _i_f _t_h_e_y _w_i_s_h _t_o _l_i_e, _t_h_e_y _m_a_y
_d_o _s_o. _A_b_o_u_t _t_h_e _o_n_l_y _t_h_i_n_g _t_h_a_t _i_s _r_e_s_t_r_i_c_t_e_d _i_s _t_h_e
_n_a_m_e _o_f _t_h_e _p_e_r_s_o_n; _c_h_a_n_g_e_s _t_o _n_a_m_e_s _a_r_e _h_a_n_d_l_e_d _b_y _m_e
_p_e_r_s_o_n_a_l_l_y _a_t _t_h_i_s _t_i_m_e. _I _h_a_d _t_o _m_a_k_e _f_i_v_e _c_h_a_n_g_e_s _i_n
_a _y_e_a_r _o_f _o_p_e_r_a_t_i_o_n.]
o+ Wide Availability of Client Software. To quote from one
of our early design documents: ``People should be able
to access the nameserver from just about anything short
of an Edsel.'' We wanted a name service that was avail-
able to anyone on our campus network. In this we have
done fairly well; we have clients for UNIX and VMS, as
well as a limited VM/CMS client. Significantly missing
are MS-DOS and Macintosh clients; we may create these at
some future time.
o+ Easy Entry of Information. With at least 50,000 entries
expected, we had to have an automated way of entering
information; ``just type it in'' was right out. In this
our NameServer gets mixed reviews. Automated entry is
used, but it is not very pleasant; witness the document,
_R_e_b_u_i_l_d_i_n_g _a _N_a_m_e_s_e_r_v_e_r _D_a_t_a_b_a_s_e _I_n _2_4 _E_a_s_y _S_t_e_p_s.
o+ Don't Pass Passwords Over the Network. With cheap eth-
ernet devices available, it is fairly easy for the aso-
cial person to tap an ethernet and grab packets. This
would allow such a miscreant to steal passwords; to
avoid this, we wanted no password to traverse our net-
works ``in the clear.'' Our Nameserver uses a random
challenge scheme that meets this requirement.
Why Did We Develop Our Own?
Some organizations suffer from NIHS (Not Invented Here Syn-
drome); if someone else did it, it's not good enough for us.
We'd like to think that does not describe us. While we were
thinking about criteria for a name service, we also surveyed the
field to see if any of the name servers then in existence were
appropriate for out task. We looked initially at two; the CSNET
Name Server and White Pages from Andrew; later, we examined NetDB
from Stanford. In tabular form, this is what we found:
Table 1. _N_a_m_e _S_e_r_v_e_r _C_o_m_p_a_r_i_s_o_n
The above comparison made it clear to us that we couldn't use
any of the three candidates as they were. They simply didn't
have the features we felt were essential. Therefore, we decided
to roll our own.
Why Did We Use the CSNET Server As a Starting Point?
We did not start completely from scratch. We decided that the
CSNET
Name Server would make a good starting point for our own name
server. Take a look at table 1 again. The CSNET server met
three out of five of our essential criteria, and four out of five
of our list of non-essentials. It fell down in three areas:
flexibility, by keeping a fixed set of information about each en-
try; capacity, by using 16 bit pointers; and the domain authori-
zation scheme, which it did not use.
Examination of the CSNET source code revealed that the two ma-
jor deficiencies, the 16 bit pointers and the inflexibility,
could be remedied very easily. The underlying database was actu-
ally fairly general, and adapted itself easily to tagged fields
and 32 bit pointers. That left only the domain authorization
scheme, which we decided we could add easily enough at a later
date. [_R_e_a_l_i_t_y: _A_s _w_a_s _m_e_n_t_i_o_n_e_d _b_e_f_o_r_e, _w_e _n_e_v_e_r _d_i_d _d_o _t_h_i_s.]
What's the Difference?
In the process of adapting the CSNET Name Server to our pur-
poses, we wound up making many changes. In fact, while we still
use a modified version of the CSNET server's database code, the
overlying software is all new. For the benefit of those familiar
with the CSNET server, let us outline the differences between the
CSNET software and our own:
o+ Pointers expanded to 32 bits. 16 bits translates into
65,000 entries (or 32,000 for signed pointers), and was
not enough. We therefore increased the pointer size.
o+ Fixed fields replaced with tagged fields. The CSNET
server had a half dozen or so null-terminated ascii
fields. Each field had to be present in every entry,
although a field could be empty. The database proper
(as opposed to the higher levels of the server) did al-
low an arbitrary number of null-terminated fields; a
little surgery was done to exploit this basic orienta-
tion. As mentioned elswhere, each entry in our database
has only non-empty fields, tagged with what kind of
field each is.
o+ One-tier authorization. The CSNET server thought in
terms of user, host, site triples. A user could change
his information. A host could change the information of
any user whose entry was ``owned'' by an account on that
host. A site could change the entry of any host identi-
fied with that site. Finally, there was a
``super-user'' entry. Further, each host and site had a
password that was used for client-server communication.
We removed this entire structure; in our Nameserver,
each user has his own password, and can use it to change
his own entry. Some users have ``hero'' privileges,
which allow them to change anything in any entry.
o+ Removal of pipe and email interfaces. The CSNET server
had
a client that could talk to it via the network, a pipe,
or electronic mail. We remove the latter two capabili-
ties (although our server can be talked to through a
pipe by server administrators). The pipe was a simple
special case of network access, and was removed without
loss of functionality (nor efficiency, since our server
is on a machine with no real users). The email inter-
face could be done, but we have had no incentive to do
it; network access has so far been sufficient.
o+ Removal of mail forwarding programs. The CSNET server
looked at mail forwarding very differently than do we;
we therefore removed that portion of the code. Mail
forwarding is done outside of the Nameserver _p_e_r _s_e, in
other programs. These programs use the Nameserver to
look up information, but are otherwise unrelated to it.
o+ New Clients. Our client software is completely dif-
ferent. The ideas are basically the same, but the com-
mands and other operational issues have all been ad-
dressed afresh.
o+ New Server-Client Protocol. Our Nameserver is talked to
very differently than the CSNET server. We found the
CSNET protocol somewhat confusing, and rather difficult
for a human to use; ours can actually be used by a _h_o_m_o
_s_a_p_i_e_n_s without great grief.
There are of course many other differences. The list above is
only intended to hit the ``high spots,'' places where we differ
in a significant manner from the CSNET product. Note that we
have not necessarily _i_m_p_r_o_v_e_d on CSNET's work; we have _a_d_a_p_t_e_d
some of it to fit our needs and desires. It may well be that the
CSNET server would be more appropriate for any given organiza-
tion. For example, if network connections are not universal our
server is a bit awkward; the built-in email interface of the
CSNET server would be quite useful in such a case.
Conclusion
We are quite pleased with our Nameserver. It meets most of our
needs, and we are confident that its flexibility and good perfor-
mance will serve us well as we use it for more purposes. Organi-
zations considering a name service are welcome to evaluate ours,
and use it if they wish (subject to the distribution conditions
outlined in _T_h_e _C_S_O _N_a_m_e_s_e_r_v_e_r, _A _D_e_s_c_r_i_p_t_i_o_n, which are li-
beral). There are however other excellent choices; your choice
will depend on your needs.
Ph Application
HISTORY
Sept, 1992, v3.3
Adaptation for NS 3.3: Re-built project to work with 3.3 project builder. Slightly modified some source files as necessary to compile (mostly changes to refer to the correct 3.x headers). Added colorized icon. Compiled for m68k and intel. Michael Giddings, giddings@whitewater.chem.wisc.edu.
April, 1992, v2.04, described below
Ph Application
The Ph application gives you access to directory information at several Universities. It is used to obtain traditional phone book information. More importantly, for e-mail users, it provides access to e-mail addresses. Some Universities provide other data such as information about courses, restaurants, and weather.
This release is a partial implementation of the Ph client. Only queries are allowed; editing has not been implemented.
CSO Nameserver Software
The Computing Services Office (CSO) at the University of Illinois Urbana-Champaign developed the CSO Nameserver software. The software consists of two programs; a server program which manages the data and a client program which handles user requests. Ph is the client program which gives you access to the data.
Many sites installed the CSO Nameserver software to simpify e-mail addresses. An e-mail address can be an alias, name, or callsign followed by the domain name. In the case of ambiguous matches, a list of possibilities is returned to allow the sender to make the next attempt successful. Sending e-mail to pruess@uiowa.edu results in an ambiguous match. Mail will be returned to the sender with valid possibilities. Sending e-mail to Rex-Pruess@uiowa.edu is a unique address and the mail will be delivered.
Even if your site does not run the CSO Nameserver software, you can still use Ph to query sites which do. As of this writing, the following sites were running the CSO Nameserver software:
Brown University Eastern Illinois University
Northwestern University Notre Dame University
Princeton University Texas A&M University
U of Arizona U of Chicago
U of Florida U of Illinois at Urbana-Champaign
U of Iowa U of Minnesota
U of Utah U of Wisconsin at Madison
U of Laval, Quebec, Canada U of Waterloo, Ontario, Canada
Roskilde Universitetscenter, Denmark
More information about the CSO Nameserver is available in the README.CSO file.
Queries
Ph ignores case and word order when performing queries; Rex Pruess, rex pruess, and Pruess Rex are equivalent and will return the same entry. The UNIX metacharacters *, ?, and [] are supported too.
Besides querying by name, you can query by other fields. For example, you can query the University of Illinois Nameserver for restaurant information. To find the restaurants serving Italian food, query with the name and other fields set to restaurant and italian respectively.
You can choose to have the Nameserver fields returned in one of three modes: default, all, or specific. In the default mode, the e-mail address is re-written as alias@domain.
Servers
Ph sends the following query command to its default Nameserver to obtain the names of other servers:
query ns-servers type=serverlist return text
Some Nameserver sites do not maintain the ns-servers record. If your default Nameserver does not return the names of other servers, ask your network administrator to add the record or switch to a different default Nameserver.
Choose Servers from the main menu to see the names of other Nameserver sites. Select a site to see its server and domain; double-click to initiate a query session with it.
Remote Help
Most Nameserver sites provide site-specific help. Choose Server from the Help menu to see the help topics. Ph obtains this help by sending the following command to the Nameserver:
help nextph
Help topics ending with ".rtf" are processed as Rich Text Format files. This allows remote sites to provide attractive help for NeXT users.
Of particular interest is the remote Nameserver site topic. Typically, this topic describes the server system, as well as providing an overview of the site's data base. Who knows, you might find a NeXT server somewhere.
Availability
Ph was uploaded to the submissions directory at a few well-known archive sites. The archive manager will move Ph to its permanent directory as his or her schedule permits. See the following chart for details.
Site Permanent Directory File
cs.orst.edu /pub/next/sources/next-interface Ph2.04.tar.Z
sonata.cc.purdue.edu /pub/next/2.0-release/source Ph2.04.tar.Z
Source code is included with the Ph distribution. It is under the terms of the GNU General Public License. Refer to the file COPYING for details.
Installation
Unpack the source code.
uncompress -cvV Ph2.04.tar.Z | tar xvf -
An executable , stripped version of Ph is provided for you. Simply copy it to the desired installation directory. Usually, this is your personal Apps directory, ~/Apps, or the system Apps directory, /LocalApps. File permission rights should be set to "rwxr-xr-x" if you want other users to be able to invoke Ph.
To re-make and install Ph from scratch, type:
cd Ph2.04
make install
Nameserver Port
If you plan to use Ph regularly, you should add the Nameserver port to your NetInfo services file. To do so, use NetInfoManager or run the following command as root.
echo "ns 105/tcp" | niload services .
Services
Ph provides query service to other applications. For example, if you are reading mail, you can select a name and issue a Ph query via the Services menu. If you use Ph often from another application, you might want to detach the Query Ph submenu for quick access. Or, if you prefer to use keyboard alternatives, you can assign them through the Preferences application.
To use the Ph services facility, you must install Ph in a standard directory, such as /LocalApps or ~/Apps. Also, you must logout /login before the new severices will appear in menus. There are known problems with service applications not recognized if installed in /LocalApps. If you encounter this problem, drag Ph to your dock and see if that helps. Or, try installing Ph in ~/Apps of /NextApps instead. Also, you should delete the ~/.NeXT/services/{.applist,.cache} files before you logout/login.
From the Preferences panel, you can select which Ph services you want to appear in Services menus.
Modifying Services
If you wish to modify the services for your particular Nameserver, you must edit the services file in the Ph subdirectory. Generally, you can mimic the entries which are already in the file. A typical entry follows:
Message: phQueryService
Port: Ph
Send Type: NXAsciiPboardType
User Data: name
Menu Item: Query Ph/Name
The Message, Port, and Send Type fields should be the same for all entries. The User Data field must contain the exact name of the corresponding Nameserver field. This must be an indexed field in the Nameserver database. The Menu Item field is the name you wish to display in the Services menu.
Use Interface Builder to update the Prefs.nib file in the info.subproj subdirectory. Update the services matrix to reflect the changes you've made in the services file. You do not need to make any source code changes, provided you continue to use the prefix Query Ph/ in the menu item names. If you change the prefix, you will need to change the SERVMENUTITLE define in the Prefs.m file in the info.subproj subdirectory.
After you've made changes, type:
make clean
make install
You will need to logout/login before the new services will appear in menus.
Speaker/Listener Methods
Ph supports some Speaker/Listener methods. Programmers wishing to make use of these methods should refer to the SpeakToPh subdirectory for more information.
The University of Minnesota's gopher application is one example of an application which uses the Ph speaker methods.
Author
Ph was written by Rex Pruess, Weeg Computing Center, The University of Iowa. He is also the author of Remotes and contributed the RPC code for NLoad.
Ph Source Files Main Directory Ph_main.m Generated by Interface Builder. Ph.m Main routine. Responsible for app initialization, among other things. There is only one Ph object. PhListener.m Generated by msgwrap Ph.msg. Listens for Ph speaker messages from other apps. There is only one PhListener object. PhSpeaker.m Generated by msgwrap Ph.msg. Ph does not use the PhSpeaker object. It is used by other applications to send messages to Ph. Ph.m Main routine. Responsible for app initialization, among other things. There is only one Ph object. info.subproj Directory Animator.m Timer routine used for Info panel animation. Other objects (eg., Query) use Animator objects too. There are multiple Animator objects. Info.m Main routine for the Info panel. Loads the info.nib file. There is only one Info object. InfoView.m Performs the Info panel animation. There is only one InfoView object. GNULicense.m Loads the GNULicense.nib file and displays the GNU License panel. There is only one GNULicense object. HelpIntro.m Loads the HelpIntro.nib file and displays the very basic Help panel. There is only one HelpIntro object. HelpServer.m Loads the HelpServer.nib file and displays the Help window for a remote server. There is a HelpServer object for each Server. HelpServerMgr.m Manages the HelpServer objects. There is only one HelpServerMgr object. Prefs.m Loads the Prefs.nib file, displays the Prefs window, and updates the defaults data base. There is only one Prefs object. qiServers.subproj Directory Qi.m Interacts with a Query Interpreter server. There is one Qi object for each server. QiField.m Each QiField object contains the number, name, keywords, and description for a specific field. There are multiple QiField objects per server. QiManager.m Manages the Qi objects. There is only one QiManager object. Servers.m Main routine for the Servers window. Loads the Servers.nib file. There is only one Servers object. Site.m Each Site object contains the name, server, and domain information for a specific site. There are usually multiple Site objects. query.subproj Directory BoxViewSwitcher.m Performs the switching between the Fields & Name box views. There is a BoxViewSwitcher object for each Query object. Query.m Main routine for the Query windows. Loads the Query.nib file. There is a Query object for each Query window. QueryFieldView.m Custom view for the two matrixes holding the icons and field forms. There is a QueryFieldView object for each Query object. QueryManager.m Manages the Query objects. There is only one QueryManager object. Specify.m Creates and manages the window containing the return field switches. There is a Specify object for each Query object.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.