# vim: set ft=text132:
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
#
#              C E D A R
#          S O L U T I O N S       "Software done right."
#           S O F T W A R E
#
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
#
# Author   : Kenneth J. Pronovici <pronovic@ieee.org>
# Project  : Cedar Backup, release 2
# Revision : $Id: TODO 623 2005-02-27 03:30:01Z pronovic $
# Purpose  : TODO list for package
#
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #


FUTURE FUNCTIONALITY

* Add a config value or option for indicating whether backed-up files should be logged (if anyone cares).
* Implement capacity mode functionality, i.e. what to do with a full disc. (bug #6)
* Implement "safe overwrite" functionality based on disc label, and give users a way to label a disc (bug #5)
* Prevent two backups from running against the same config file (?)
* Make incremental backup safer if full is missed, i.e. "expire" incremental stuff after a week? (bug #6)
* Somehow figure out if a full backup (i.e. disc-restart) has been missed (bug #6)
* Perhaps update configuration to disallow two extensions with same name (right now, behavior is undefined).
* Perhaps update configuration to disallow two peers with same name (right now, behavior is undefined).
* Would be nice if "XXXX bytes" output could be in engineering notation or something - ByteQuantity object or something?


TESTING IMPROVEMENTS

* Create unit tests for the store/rebuild "find directories" functions in action.py (and maybe refactor)
* Come up with non-PyUnit code to stress test high-actions, etc. 


PLANNED EXTENSIONS

* Create Subversion extension (initially, for backing up Berkely DB repositories)
* Create "system info" extension to dump fdisk information, etc. to collect directory.
* Create MySQL extension to back up MySQL databases like Bugzilla.


DOCUMENTATION IMPROVEMENTS

Documentation in some places is difficult to read, especially in the config section.

Julie has some ideas for how I can fix it.  In particular, she suggests that I shouldn't
duplicate description unless I have to (i.e. ignore file in two places) and she suggets
that I be clearer (or at least more consistent) in the way I discuss whether a field is
optional, required, can be repeated, etc.

Julie also thinks that I may be able to rework the setup sections (master and client)
to avoid duplication.  There is a lot of duplication there, but I'm kind of at a loss
as to the best way to present it to the user.  I'm not sure if it's better to have
completely different sections or one section with "if master, do this, if client do this"
in it.


