Knowledge Base Setup
This page contains some notes on how and where the existing knowledge base servers are setup, and what files they use...
Currently, there are two places that knowledge base servers (KBDs) exist--on the SGIs and the NEXTs. On both machines, everything currently resides inside my home directories. The path is ~bradley/src/slispapps/kbd. In this diretory may be a number of shell scripts that start with the letters "kbd". These are the knowledge base server exectuables. They each run the siserver binary exectuable (in ~bradley/bin) with a different "init" file. The init files, and other lisp function files are in the directory here named lsp. Each init file will set up the specific variables for determining where to get the database info it needs, and what lisp functions to use. See the section on init files for more on this.
The siserver program is compiled differently on each different type of machine. On the NEXTs, it is compiled with a module named xsybase that allows it to connect to the sybase database server. On the SGIs, it is compiled with a module named xmsql which allows it to connect to an msql server running on any unix machine on the network (which, coincidentally, won't run on the NEXT). Both machines are running the newest version of siserver, with the new modifications to the core module, that enable it to run as a standalone server, as opposed to running via inetd. On both systems, the binaries are located in ~bradley/bin
On patella (a NEXT), there are inetd.conf entries that allow you to connect to the KBDs kbd and kbdtest via the port numbers 5202 and 5203 via an inetd connection. This means that they do not have to be started up before they can be used.
On the SGIs, or any other NEXT, there is no inetd
version setup, so you must use standalone mode.
To run any of the KBDs in standalone mode, it
simply needs to be passed the command line
argument '-pXXXX', where XXXX is a port number it
should listen to. This starts up a few daemon processes
that take turns listening to that port for incoming connections.
Example:
% kbdtest -p7000 &
Note that you have to run it in the background with the '&'.
Running standalone daemons on different machines of the same type, it is possible to use the same executable. Currently, the java-based knowledge browser connects to the SGI brain.biostr on port 7000 and the web atlas software running on avalo connects to the SGI avalo on port 7000, and they were started up from the KBDs kbdtest and kbd-brain, respectively.
if the system goes down, it is necessary to manually restart the kb server (and the database server too) unless someone make an entry to start up the server in /etc/rc2.
On the NEXTs there are two init filesL kbdinit.lsp and kbdtestinit.lsp. They are used bythe KBDs kbd and kbdtest, respectively. Currently both are the same, but if you wanted to develop new features, you'd write them in a separate file and only load them from kbdtestinit.lsp that way they won't interfere with the production version. This is the way it should work on the SGIs too, but hasn't really been setup yet.
On the SGIs, there are two init files: kbdtestinit.lsp and kbdbraininit.lsp. These are used by KBDs kbdtest and kbd-brain respectively. kbdtest is used by the java knowledge browser and is run on brain. kbd-brain is used by John Sunsten's brain atlases, and is run on avalo. The primary difference, at the moment, is that kbd-brain points to a different directory for it's glossary definitions.
The files kbfuncs.xxxx.lsp are the lisp functions that make up the knowledge base functionality. Because they directly access the database, there needs to be a different version for each database supported. There are currently two versions: kbfuncs.sybase.lsp and kbfuncs.msql.lsp. The first is for sybase, and is out of date as far as functionality is concerned, and can only be used with a version of siserver that has been compiled with the xsybase module. The latter is for use with msql, and is the current development version of the knowledge base functionality, and can only be used with a version of siserver that has been compiled with the xmsql module.