[Zope-Checkins] SVN: Zope/trunk/doc/ moved

Andreas Jung andreas at andreas-jung.com
Fri Feb 20 10:29:53 EST 2009


Log message for revision 96828:
  moved
  

Changed:
  D   Zope/trunk/doc/TODO.txt
  A   Zope/trunk/doc/obsolete/TODO.txt

-=-
Deleted: Zope/trunk/doc/TODO.txt
===================================================================
--- Zope/trunk/doc/TODO.txt	2009-02-20 15:29:41 UTC (rev 96827)
+++ Zope/trunk/doc/TODO.txt	2009-02-20 15:29:53 UTC (rev 96828)
@@ -1,212 +0,0 @@
-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.

Copied: Zope/trunk/doc/obsolete/TODO.txt (from rev 96821, Zope/trunk/doc/TODO.txt)
===================================================================
--- Zope/trunk/doc/obsolete/TODO.txt	                        (rev 0)
+++ Zope/trunk/doc/obsolete/TODO.txt	2009-02-20 15:29:53 UTC (rev 96828)
@@ -0,0 +1,212 @@
+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.



More information about the Zope-Checkins mailing list