[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