SDS can be used in server-mode and no-server mode and no-server mode is default. I cannot guarantee the security of the server and it is best run behind a firewall. The server is basically a Read-Eval-Print loop which reads commands on a port. Currently only one command is allowed (run-known-program) and this is checked. However if you don't want to open a port for reading lisp-commands you can make all tools start a lisp-image on the command-line for executing the program. This is (much) slower but safer. This safe option is also the default, you have to explicitly turn the server on.

Server

The essential part of using SDS as a server is to get the SDS server running. The easiest way to do that is to use the start-sds-server.sh script in a dedicated xterm. The xterm will be occupied by the server as long as the server is running.

This server-xterm can be used for debugging and will probably spew out all sorts of nonsense which will look dangerous with many error-messages and warnings. Don't worry. It is quite ok. The server will read $HOME/.sds/prefs.xml if it can and use the server preferences, e.g:

  <general serveruse="yes">
  </general>
    
  <server name="palomba"
	  host="127.0.0.1"
	  port="5544"
	  user="stig"
	  password="&quot;fooie&quot;"/>

A template for the user-prefs file may be found as glob-prefs.xml in tests/ in the source-tree or $PREFIX/share/sds/tests/ where sds is installed. The information in this file will also be used by the clients, so this is the important file. The PORT and the PASSWORD is taken and used directly from this file. The HOST is also used by the clients as it should, and it is used correctly on the server-side by CMUCL and ACL. But in CLISP one cannot specify listening ip because CLISP thinks it knows better so you might need to set this address to whatever address CLISP figures out is right for you. On my computer it never chooses the loopback (127.0.0.1) so I have to use 192.168.1.1 as HOST to allow the client to connect. Annoying.

If the shellscript won't start the server, there are two other ways to start the server. The easiest is to use the FAS/FASL/X86F file generated during 'make' and installed in /usr/lib (probably) as sds-sys.FASLEXT where FASLEXT is the extension of compiled files for your lisp. What you do is:

$ lisp
> (load "/usr/lib/sds-sys")
> (sds-user:sds-server)

This will load SDS and start the server. The other method, which I use during development is to have src/clisp/ in the source-tree as cwd, and then start lisp:

$ lisp
> (load "build")
> (sds-user:sds-server)

The last source-based method is slowest and will do extra checking and compiling and is best avoided unless you're developing or customising. Or you're me.

If you do not provide a preference-file, some defaults will be used:

host:     localhost (127.0.0.1)
port:     5544
password: fooie

These defaults are hardcoded into the server and the clients, but it is recommended that you customise a preference-file.

Clients

Most of the clients (csf2csf, csf2sdoc, sdoc2doc, ...) all use a python-script to do the actual connection. This python-script, sdsclient.py, will use the user preference-file as described in the server-part above. It also takes a few options which is not passed to the actual underlying programs:

--host HOSTNAME
--port PORTNUMBER
--pwd  PASSWORD

These can be used to override default-values and values in the user preference-files.

The clients all have some options in common, which are answered by the actual client:

-h       or  --help        prints help and quits
-i       or  --info        prints out settings for the program
-p FILE  or  --prefs=FILE  specify preference-file to use
-v       or  --verbose     be really chatty
-V       or  --verify      where appropriate, spend much time verifying data

Most clients will via the python-client call a function on the sds-server, RUN-KNOWN-PROGRAM, where the first argument is the path where the program is run from, the second is the name of the program and the rest of the arguments are the arguments to the actual program.

(defun run-known-program (base-path program-name &rest args)
  "Runs a known program in a pretty way.. "
  ...)