TODO list for PTS.  (Personal notes...may not make sense to anyone but myself.)
==================
(*see also TODO lists in each subdirectory*)


----------------------------------------------------------------------
1.  Better error messages!  More error checking!

2.  <COMPLETED>

3.  <COMPLETED>

4.  <COMPLETED>

5.  Add networked database capabilities...Listen to a port for requests.
CLIENT/SERVER functionality.  Should be able to build server on top
of existing zdbm and modify existing cloud to make calls to zdbm-server
instead of directly to zdbm.  Maybe not really change the cloud,
but just link the cloud to a different set of zdbm functions that
don't really do what they're named but instead contact the server
and IT does the action.  Major possiblilties here.

6.  The curses user interface.  Finish it.

7.  MS-Windows user interface.  Go for it.

8.  Use environment variables, particularly for the curses interface.
    Allow the database config file to be specified by env. vars.

9.  Allow the database config file to be specified on the command-line.

10.  Somehow we need to allow the config file to be re-read, for when
new problem types are added to the database.  (Not that critical).

11.  Finish Web/PTS!!!

12.  Allow "delete problem" to be disabled, since some sites want it
     to be impossible to delete problems.  While we're at it we should
     have it send e-mail to someone if their *unsolved* problem has
     been deleted.



----------------------------------------------------------------------
MAYBES:
-------
M1.  Somehow inform sysop users which problems have been worked on since
their last xpts session.  Need a ~/.xptsrc ?

M2.  Add a layer between the executable pts and "the cloud".
This layer would be whichever user interface library you want
to link to.  The application would be the same for all
user-interface libraries.  May only work for similar libraries
(ie GUI, since curses might be too different.)

M3.  Motif user interface.  For those w/out Athena widgets.  Maybe not.


======================================================================
COMLETED: (moved from above lists after completion...)
2.  Add the ability to specifiy the top of the database in the config file.
This is VERY important, since it extends the usefulness of PTS to other 
situations.  Keeping track of problems for any type of team effort, 
such as a software design team.  The point is that you could have multiple
PTS databases without rebuild PTS.

3.  Add the ability to specify these in the config file, too, instead of
only at compile time:
	print-command
	mail command
	database locaton

4.  Add the capability to send mail to certain users when problems IN CERTAIN
LEAVES are over a set number of days old.  For example, we might have 
all problems in /Software/PTS-Problems be mailed to Zombie Software.

