To Do:

General
--------

- Change to using the options hash from GetOpt::Std instead of the individual
option variables like $opt_v.

- Use the "if (defined $opt_l)" construct for checking options?

- Move the parsing of at least some options in the bin/* scripts into a
subroutine, or subroutines depending on the options?

- Organize the display of the options in a script Help Message by which command
they are associated with.

- Variables should only be declared at the highest level they are needed; i.e.,
if a variable is only used in a subroutine, it should only be declared there
and not declared globally.

- Need to clarify the parameters for $db_option{'Name'} & $database? For
instance;  to differientate between the database name as part of the DSN used
to connect to a database server and the name of a database being created or
dropped on a server.

- The option used to define which type of database to use does not currently
do any error checking on that type;  the script will fail if a correct DBD name
is not used.  If do not explicitly do such error or other checking, document
the standard names for DBI DBD modules like SQlite (default), mysql, cvs, and
postgresql.

- The use of special characters like periods in table names is a more general
issue where it is not a good idea to use them at all.  Redo the comments in
scripts and modules regarding that, to generalize it.  (Derive function to
validate it and add th at to the FTN::Database module?)

- Change this TODO document into being a pod document, perhaps explicitly as
something like the module FTN::Database::ToDo? 

- Separate out the submodules, like FTN::Database::Nodelist and
FTN::Database::Echolist (when implemented), into separate distributions
so that only the functionality that's wanted needs to be installed?


FTN::Database
--------------
- Export the commonly used functions by default.
- Rename the create_ftndb subroutine to create_ftn[db]_database.
- Derive a generic create_ftn_table subroutine from the create_nodelist_table
  function in FTN::Database::Nodelist, using a variable in the sql for the
  table definition. Then change the create_nodelist_table function to use it.
- Derive a generic drop_ftn_table subroutine from the drop_nodelist_table
  function in FTN::Database::Nodelist.
- Derive a generic drop_ftn_index subroutine from the drop_ftnnode_index
  function in FTN::Database::Nodelist.
- Create set_ftndb_acl subroutine? (Same reasoning as for create_ftndb.)
- Possible function/subroutine that checks if a valid database table name is
  being used?  And corrects it if possible?


FTN::Database::Nodelist
------------------------
- Export the commonly used functions by default.
- Derive and move a function for executing queries on the nodelist table from
  the code used in the list_ftn_nodelist subroutine.
- As part of adding statistics related functions, add a function that counts
  the number of nodes that have a particular flag associated with it?  Could
  use the name "get_nodelist_flag_count ($dbh, $table_name, $nodelist_flag)"
  but how to build in extra parts of the search for things like "zone = 1"?
  Also add something that counts the number of things like hubs, nodes marked
  as private, etc?
- Derive and move function to insert or update an entry from ftnpldb-nodelist.
  Separate functions for insert & update, or different options in same function?
- Move get_nodelist_filename subroutine from the ftnpldb-nodelist script?
- Use a different datatype than "TIMESTAMP" for the 'updated' field in the
  nodelist table?  (Not generic enough?)
- Use a template framework of some sort instead of the builtin 'format' 
  operations for the reporting functionality. 

  
ftnpldb-admin
-------------- 
- Pass the variables to subroutines directly, rather than depend on the globals.
- Come up with a single option for the name of the object being created or
  dropped, to replace the -d & -t options for the database_name and the
  nodelist_table_name variables?  Perhaps "-N" ?


ftnpldb-nodelist
----------------
- Move code for processing the -f & -e options into a separate subroutine, so
  it could be used by more than just the load command?
- Add an option, like -r, for specifying a region number;  to be used like the
  -z or -n options, and for all commands.  
- Add cammands to create or drop the ftnnode index on the nodelist
  table?
- Move create_ftn_nodelist_table from ftnpldb-admin to ftnpldb-nodelist, but also
  leave a generic create_ftn_table subroutine there in ftnpldb-admin. 
- Add the type field to the List command output?  Redo the header (extra line)?
- Script does not seem to properly handle a file that ends in just blank
  lines, instead of a content line or a ^Z character. (Should fail gracefully
  for a badly formatted file.)
- The list of nodelist files is being reverse sorted when there are multiple
  nodelists of the same basename being processed;  that takes care of a set
  of files all from the same year but not ones that are from different years.
- Add a test nodelist for use with this?...


FTN::Database::Echolist
------------------------
- Create an FTN database module for echolists which:  Creates or Drops an
  echolist table, default name "Echolist"?  Basic table would consist of
  (at least) the following fields:  name, description, source.
- Export by default the commonly used functions.
- Create or drop an index on that basic echolist table.
- Create an ftnpldb-echolist script, patterned after ftnpldb-nodelist, which
  can be used to load the echolist table.


Testing
-------
- Procedure in test script?    
1) get temp directory
2) create working directory there
3) ...  testing...
4) remove test working directory
5) done
  