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.
