Removed todo. All of the mentioned items are really outdated.

doc/obsolete/TODO.txt

-The following is a TODO list dealing with installation and startup
-changes proposed for the Zope trunk.  It is organized into these
-categories:
-
-  "BEFORE 2.7 FINAL" (things that need to be done before we're
-  finished, but not currently on the critical path)
-
-  "MAYBE NEVER BUT NICE TO HAVE" (items that are not on any critical
-  path)
-
-  "COMMUNITY CONCERNS" (uncategorized concerns dealing with features
-  missing from HEAD and prior 2.7 releases)
-
-----------------------------------
-  BEFORE RELEASE OF ZOPE 2.7 FINAL
-----------------------------------
-
-Provide more intuitive command line option overrides
-
-  Currently, you can override config file options by using the
-  -X command line switch to runzope.py, followed by key/value
-  pairs separated by an equal sign.
-
-  This isn't explained anywhere and I'm not sure what limitations
-  it has (can you change any value in the config file this way?).
-
-  Zope-specific command-line options that don't require the -X
-  (e.g. --event-log-file=something) should be provided to the
-  user via changes to Zope/Startup/options/ZopeOptions.
-
-Make 'runzope -h' work and give better error messages when a configuration
-fails to make the grade.
-
-  Currently runzope -h just emits a traceback, and the message printed by
-  run.py says to run 'run.py -h' which can't work because things that
-  it needs to import aren't on the PYTHONPATH.
-
-Config file needs better inline docs
-
-  The Zope ZConfig config file has some inline docs.  They need to be
-  completed.  Additional docs may come as a result of writing a schema-to-HTML
-  translator.
-
-Make as many things defaultable as feasible
-
-  Maybe we can allow a config file in which everything is commented
-  out. We'll see.
-
-Write some more unit tests
-
-  Write unit tests for Zope.Startup packages.
-
-What to do about envvars?
-
-  Envvars are still used "under the hood" in ZConfig handlers as the
-  result of particular configuration declarations in order to make
-  Zope do the right thing (e.g. INSTANCE_HOME, SOFTWARE_HOME,
-  DTML_REQUEST_AUTOQUOTE, SESSION_TIMEOUT_MINUTES and other envvars
-  are set in ZConfig handlers for their respective keys).  But envvars
-  should not be used to try to configure Zope, as the handlers
-  overwrite existing envvars with prejudice.  We need to come down on
-  one side or the other about envvars.. either they should be
-  respected at startup as they always have been or they should be
-  explicitly not respected.  Currently they are not respected.
-
-  We need to communicate this decision to developers and update
-  doc/ENVIRONMENT.txt as necessary.
-
-win32-eventlog needs testing
-
-  The "win32-eventlog" log handler (which is creatable via the config
-  file) needs to be tested.
-
-  Note: As of Jul 6, 2003, it has been confirmed to not work.  The
-  service name that it is logging under ("Zope") is not registered
-  with the NT event service properly, causing a warning to be
-  written to the log every time a log call is made.
-
-Server construction errors need to be better
-
-  When a server is constructed, it attempts to bind to a port.  If the
-  port cannot be bound, an error is raised.  The error currently doesn't
-  include the port number, and should.
-
-I propose that we add two more options to the config file:
-
-  Create import-directory and extensions-directory directives
-
-  These would both be multikeys which specify some number of
-  directories that contained importable zexp files and external
-  methods, respectively.  This would allow us to not require any fixed
-  instance home directory.  Instead, each path required by each
-  subsystem is specifiable by itself in the config file.
-
-  I'm sure that utilizing these options in the config file will break
-  things that rely on having a monolithic INSTANCE_HOME such as
-  products that attempt to do something like "import_dir =
-  os.path.join(INSTANCE_HOME, 'import').
-
-  So I propose that the stock Zope instance home install continue to
-  follow the old pattern (where everything is installed into a single
-  instance home directory), but we provide the advanced config file
-  options for roll-your-own packagers and advanced users.
-
-  I would like to do the same thing for the software home, but I
-  haven't thought much about it yet.
-
-Review the Zope Book 2.6 Edition chapters and come up with revisions
-or at least create a Zope 2.7 Install HowTo
-
-  The 2.6 edition Zope Book at
-  http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition has
-  three chapters which detail installation (Installing and Starting
-  Zope), maintenance (Maintaining Zope) and ZEO (Scalability and ZEO).
-  These chapters should be reviewed for inaccuracies with respect to
-  the forthcoming trunk changes and changes should be made "offline"
-  to allow a Zope Book 2.7 edition.
-
-  At least create a HowTo which summarizes the differences between
-  installing 2.6 and installing 2.7.
-
-------------------------------
- MAYBE NEVER BUT NICE TO HAVE
-------------------------------
-
-ZConfig defaults
-
-  We deferred several issues that we recognized as areas for
-  improvement in ZConfig that might make it possible to avoid writing
-  nasty procedural code for default handling unnecessary
-  (e.g. Zope.Startup.handlers.root_handler).  See
-  http://my.zope.com/CPM/CPM/issues/4 and
-  http://my.zope.com/CPM/CPM/issues/3.  Not necessary for merge, but
-  useful to think about for future.
-
-ZConfig should keep enough state to be able to reconstitute the
-textual representation of the configuration.
-
-  It would be nice if ZConfig kept enough state to be able to
-  reconstitute the configuration in textual representation
-  (to aid GUI builders and to make it possible to have
-   a meaningful 'zopectl showconfig' or somesuch).  
-
-----------------------------------
-COMMUNITY CONCERNS (uncategorized)
-----------------------------------
-
-Status:  Request for comment sent to the community:
-http://mail.zope.org/pipermail/zope-dev/2003-March/018999.html
-Lots of discussion!
-
- - ZConfig is too complex when compared with envvar parsing.
-
- - Somewhat unrelated, but the features of "debug mode" should be
-   disentangled from one another and specifiable individually.
-
- - Need to support arbitrary storage types.
-
- - Provide --swhome and ---with-python switch to mkzopeinstance, which will
-   allow folks to create an instance that points to particular (known)
-   Python versions and software homes.
-
-   XXX This doesn't make sense.  mkzopeinstance is part of the
-   software home; if you want to use a different one, use the
-   mkzopeinstance from the software home you want to use.  The same
-   goes for the Python to use; that's "built-in" to a software home.
-   Using a different Python doesn't make sense given that the software
-   home includes compiled modules.
-
-   AAA This is to service to-be-chrooted installs.
-
- - Explain how to set up and use a ZEO server using mkzeoinst
-   included in 2.7's ZEO.
-
-   (Use the installed bin/mkzeoinstance script; use --help for more
-   information.)
-
-   Richard Jones has done work to allow you to create a ZEO instance
-   in a way similar to creating a Zope instance (yay!) after
-   creating a software home.
-
- - Give ZConfig replacement access to the environment or shell
-   somehow.  For instance, some folks use the same 'start' script in
-   all of their instances right now (under 2.6).  The script does
-   things based on the value of an envvar that can be used to
-   distinguish the config values of the instance from other instances.
-   We could allow for the same sort of behavior E.g.:
-
-   %define HOSTNAME `hostname`  (assuming `hostname` resolves to a hostname)
-
-   lockfile-name /var/lock/$HOSTNAME-lockfile
-
- - Give installaler an option to put libs in a user-specifiable
-   directory at software home installation time.
-
- - Give installer an option to put docs in a user-specifiable directory
-   at software home installation time.
-
- - Make it possible to install Zope-related Python libraries to
-   The site-packages of the Python used to invoke setup.py.
-
- - Offer to install software home 'bin' scripts into a directory
-   separate from the software home 'bin' directory.
-
- - Allow for the installation of platform-dependent files (basically
-   Python extensions) to be installed to a place separate than that of
-   platform independent files (as requested by Luca DeVitis).
-
- - Upon failure of Windows service startup, it's possible for the
-   reason for the failure to not be logged anywhere.  This is because
-   we carefully wait til late in the startup process to write logfiles
-   so UNIX has a chance to setuid.  This is unnecessary for Windows.