APACHE 2.x ROADMAP
==================
-Last modified at [$Date: 2002/10/17 17:16:04 $]
-
-
-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.1-stable and Apache 2.2-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.{odd}.{revision}
-------------------------------------
-All even numbered releases will be considered stable revisions. That means;
-
- * Forward Compatibility; users are not required to find new downloads of
- currently loaded modules to upgrade from other revisions of the same
- version. To upgrade from 2.1.0 and 2.1.27 will require no new modules.
- However, the third party modules may break from buggy code, or code that
- used an undocumented side effect of an API call, which may be changed to
- close bugs or security vulnerabilities. Modules should be retested.
- Moreover, new APIs may be introduced within the lifespan of the release,
- and it is up to the third party module author to call out what version
- forward this module is compatible with (e.g. "Compatible with Apache
- HTTP Server version 2.1.12 and foward.") The next stable release that
- causes module incompatibility for 2.1.x users will be an upgrade to
- either the current 2.2.x-development releases or the 2.3.0-stable release.
-
- * No Deprecated modules; although new modules may be introduced within the
- stable release, no loadable modules or their directives will be removed
- within the lifetime of a given stable release version. The next release
- that deprecates old modules for 2.1.x users will be an upgrade to either
- the 2.2.x-development release or the 2.3.0-stable release.
-
- * Warnings should be provided in the documentation to give users a heads up
- that a given module or directive will disappear in the future release,
- and advise developers that a given API will change. However, it is always
- best to check the corresponding development release to determine the full
- impact of such changes.
-
- * No 'Experimental' modules; while it may be possible (based on API changes
- required to support a given module) to load a 2.2-development module into
- a 2.1-stable build of Apache, there are no guarantees. Experimental
- modules will be introduced to the 2.2-development versions and either
- added to 2.1-stable once they are proven and compatible, or deferred
- to the 2.3-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.{even}.{revision}
------------------------------------------
-All even 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
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
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
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.
projects / apache / blobdiff