Update.

[apache] / ROADMAP

diff --git a/ROADMAP b/ROADMAP
index 58f0d282d70a8d35c20452da9a7b9ba5dd3feb4e..4c8078002e9725d7f11923879167a976e634a729 100644 (file)
--- a/ROADMAP
+++ b/ROADMAP
@@ -1,124 +1,6 @@
 APACHE 2.x ROADMAP
 ==================
 APACHE 2.x ROADMAP
 ==================

-Last modified at [$Date: 2002/10/17 17:59:17 $]
-
-
-INTRODUCTION
-------------
-The Apache HTTP Server project must balance two competing and disjoint
-objectives: maintain stable code for third party authors, distributors and
-most importantly users so that bug and security fixes can be quickly adopted
-without significant hardship due to API changes; and continue the development
-process that requires ongoing redesign to work around earlier oversights in
-the implementation of a fluid and flexible API.
-
-The Apache HTTP Server versions, through 2.0, used the Module Magic Number
-to reflect the relatively frequent API changes.  This had the shortcoming
-of often leaving binary download users hunting to replace their loaded third
-party modules.  This left the third party module authors searching through
-the API change histories to determine the new declarations, APIs and side 
-effects of making the necessary code changes.  
-
-With the simultaneous release of Apache 2.2-stable and Apache 2.3-development,
-the Apache HTTP Server project is moving to a more predictable stable code
-branch, while opening the development to forward progress without concern
-for breaking the stable branch.  This document explains the rationale between
-the two versions and their behavior, going forward.
-
-
-STABLE RELEASES, 2.{even}.{revision}
------------------------------------- 
-
-All even numbered releases will be considered stable revisions. 
-
-Stable revisions will retain forward compatiblity to the maximum
-possible extent.  Features may be added during minor revisions, and
-features may be deprecated by making appropriate notations in the
-documentation, but no features may be removed.
-
-In essence, that implies that you can upgrade from one minor revision
-to the next with a minimum of trouble.  In particular, this means:
-
-  * The Module API will retain forward compatibility.
-    It will not be necessary to update modules to work with new
-    revisions of the stable tree.
-
-  * The run-time configuration will be forward compatible.
-    No configuration changes will be necessary to work with new
-    revisions of the stable tree.
-
-  * Compile-time configuration will be forward compatible.
-    The configure command line options that work in one release
-    of the stable tree will also work in the next release.
-
-As always, it will be necessary to test any new release to assure
-that it works correctly with a particular configuration and a 
-particular set of modules, but every effort will be made to assure
-that upgrades are as smooth as possible.
-
-In addition, the following development restrictions will aid in 
-keeping the stable tree as safe as possible:
-
-  * No 'Experimental' modules; while it may be possible (based on API changes
-    required to support a given module) to load a 2.3-development module into
-    a 2.2-stable build of Apache, there are no guarantees.  Experimental 
-    modules will be introduced to the 2.3-development versions and either
-    added to 2.2-stable once they are proven and compatible, or deferred
-    to the 2.4-stable release if they cannot be incorporated in the current
-    stable release due to API change requirements.
-
-  * The stable CVS tree must not remain unstable at any time.  Atomic commits 
-    must be used to introduce code from the development version to the stable 
-    tree.  At any given time a security release may be in preparation, 
-    unbeknownst to other contributors.  At any given time, testers may be
-    checking out CVS head to confirm that a bug has been corrected.  And as
-    all code was well-tested in development prior to committing to the stable
-    tree, there is really no reason for this tree to be broken for more than 
-    a few minutes during a lengthy commit.
-
-
-DEVELOPMENT RELEASES, 2.{odd}.{revision}
------------------------------------------
-All odd numbered releases designate the 'next' possible stable release,
-therefore the current development version will always be one greater than
-the stable release.  Work proceeds on development releases, permitting
-the modification of the MMN at any time in order to correct deficiencies 
-or shortcomings in the API.  This means that third party modules from one 
-revision to another may not be binary compatible, and may not successfully
-compile without modification to accomodate the API changes.
-
-The only 'supported' development release at any time will be the most
-recently released version.  Developers will not be answering bug reports
-of older development releases once a new release is available, it becomes
-the resposibility of the reporter to use the latest development version
-to confirm that the bug still exists.
-
-Any new code, new API features or new ('experimental') modules may be
-promoted at any time to the next stable release, by a vote of the project
-contributors.  This vote is based on the technical stability of the new
-code and the stability of the interface.  Once moved to stable, that feature
-cannot change for the remainder of that lifetime of that stable verions,
-so the vote must reflect that the final decisions on the behavior and naming 
-of that new feature were reached.  Vetos continue to apply to this choice
-of introducing the new work to the stable version.
-
-At any given time, when the quality of changes to the development branch
-is considered release quality, that version may become a candidate for the
-next stable release.  This includes some or all of the API changes, promoting
-experimental modules to stable or deprecating and eliminating older modules
-from the last stable release.  All of these choices are considered by the
-project as a group in the interests of promoting the stable release, so that
-any given change may be 'deferred' for a future release by the group, rather 
-than introduce unacceptable risks to adopting the next stable release.
-
-Third party module authors are strongly encouraged to test with the latest
-development version.  This assures that the module will be ready for the next
-stable release, but more importantly, the author can react to shortcomings
-in the API early enough to warn the dev@httpd.apache.org community of the
-shortcomings so that they can be addressed before the stable release.  The
-entire onus is on the third party module author to anticipate the needs of
-their module before the stable release is created, once it has been released
-they will be stuck with that API for the lifetime of that stable release.
+Last modified at [$Date$]

 
 
 WORKS IN PROGRESS
 
 
 WORKS IN PROGRESS


@@ -150,20 +32,6 @@ WORKS IN PROGRESS
       Remember, it just takes cvs diff -b (that is, --ignore-space-change)
       to see the code changes and ignore that cruft.  Get editing Justin :)
 
       Remember, it just takes cvs diff -b (that is, --ignore-space-change)
       to see the code changes and ignore that cruft.  Get editing Justin :)
 

-    * revamp the input filter syntax to provide for ordering of
-      filters created with the Set{Input|Output}Filter and the
-      Add{Input|Output}Filter directives.  A 'relative to filterx' 
-      syntax is definately preferable.
-
-    * Platforms that do not support fork (primarily Win32 and AS/400)
-      Architect start-up code that avoids initializing all the modules 
-      in the parent process on platforms that do not support fork.
-
-    . Better yet - not only inform the startup of which phase it's in,
-      but allow the parent 'process' to initialize shared memory, etc,
-      and create a module-by-module stream to pass to the child, so the
-      parent can actually arbitrate the important stuff.
-

     * Replace stat [deferred open] with open/fstat in directory_walk.
       Justin, Ian, OtherBill all interested in this.  Implies setting up
       the apr_file_t member in request_rec, and having all modules use
     * Replace stat [deferred open] with open/fstat in directory_walk.
       Justin, Ian, OtherBill all interested in this.  Implies setting up
       the apr_file_t member in request_rec, and having all modules use


@@ -186,13 +54,15 @@ WORKS IN PROGRESS
            available for the life of the request, so a complete 
            async implementation would need to happen 3.0 release.
 
            available for the life of the request, so a complete 
            async implementation would need to happen 3.0 release.
 

-    * Add a string "class" that combines a char* with a length
-      and a reference count.  This will help reduce the number
-      of strlen and strdup operations during request processing.
-      Including both the length and allocation will save us a ton 
-      of reallocation we do today, in terms of string manipulation.
-
-        OtherBill asks if this is really an APR issue, not an HTTPD issue?
+        Brian notes that async writes will provide a bigger
+        scalability win than async reads for most servers.
+        We may want to try a hybrid sync-read/async-write MPM
+        as a next step.  This should be relatively easy to
+        build: start with the current worker or leader/followers
+        model, but hand off each response brigade to a "completion
+        thread" that multiplexes writes on many connections, so
+        that the worker thread doesn't have to wait around for
+        the sendfile to complete.

 
 
 MAKING APACHE REPOSITORY-AGNOSTIC
 
 
 MAKING APACHE REPOSITORY-AGNOSTIC


@@ -321,7 +191,7 @@ MAKING APACHE REPOSITORY-AGNOSTIC
       than calling apr_dir_open/read/close(), a caller uses
       resource->repos->get_children() or somesuch.
 
       than calling apr_dir_open/read/close(), a caller uses
       resource->repos->get_children() or somesuch.
 

-      Note that things like mod_dir, mod_autoindex, and mod_negotation
+      Note that things like mod_dir, mod_autoindex, and mod_negotiation

       need to be converted to use these mechanisms so that their
       functions will work on logical repositories rather than just
       filesystems.
       need to be converted to use these mechanisms so that their
       functions will work on logical repositories rather than just
       filesystems.