-APACHE 2.x ROADMAP:
+APACHE 2.x ROADMAP
+==================
+Last modified at [$Date$]
-Last modified at [$Date: 2002/10/01 16:51:10 $]
-DEFERRRED FOR APACHE 2.1
+WORKS IN PROGRESS
+-----------------
* Source code should follow style guidelines.
OK, we all agree pretty code is good. Probably best to clean this
dislike a bit within that doc, bring it up on the dev@httpd
list prior to the next branch.
-
-WORKS IN PROGRESS (PERHAPS DEFERRED FOR 2.1 or 3.0)
-
- * 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.
+ So Bill sums up ... let's get the code cleaned up in CVS head.
+ Remember, it just takes cvs diff -b (that is, --ignore-space-change)
+ to see the code changes and ignore that cruft. Get editing Justin :)
* Replace stat [deferred open] with open/fstat in directory_walk.
Justin, Ian, OtherBill all interested in this. Implies setting up
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
should get fully resolved. None of this "resolve to
<here> and then we have a magical second resolution
(inside the CGI script)" or somesuch.
-
+
+ Justin: Well, let's consider mod_mbox for a second. It is sort of
+ a virtual filesystem in its own right - as it introduces
+ it's own notion of a URI space, but it is intrinsically
+ tied to the filesystem to do the lookups. But, for the
+ portion that isn't resolved on the file system, it has
+ its own addressing scheme. Do we need the ability to
+ layer resolution?
+
* The translate_name hook goes away
Wrowe altogether disagrees. translate_name today even operates
should be exposed, from the core, for other file-based stores to
share. Consider an archive store where the layers become
<Directory path> -> <Archive store> -> <File name>
-
+
+ Justin: How do we map Directory entries to Locations?
+
* The "Location tree" is an in-memory representation of the URL
namespace. Nodes of the tree have configuration specific to that
location in the namespace.
it? eeewwwww...
I'll vote -0.9 for CGIs as a filter. Keep 'em handlers.
+
+ Justin: So, do we give up executing CGIs from virtual repositories?
+ That seems like a sad tradeoff to make. I'd like to have
+ my CGI scripts under DAV (SVN) control.
+
+ * How do we handle overlaying of Location and Directory entries?
+ Right now, we have a problem when /cgi-bin/ is ScriptAlias'd and
+ mod_dav has control over /. Some people believe that /cgi-bin/
+ shouldn't be under DAV control, while others do believe it
+ should be. What's the right strategy?