Log message for revision 96839: Removed todo. All of the mentioned items are really outdated.
Changed: D Zope/trunk/doc/obsolete/TODO.txt -=- Deleted: Zope/trunk/doc/obsolete/TODO.txt =================================================================== --- Zope/trunk/doc/obsolete/TODO.txt 2009-02-20 15:56:46 UTC (rev 96838) +++ Zope/trunk/doc/obsolete/TODO.txt 2009-02-20 16:03:39 UTC (rev 96839) @@ -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. _______________________________________________ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins