APACHE 2.x ROADMAP:

Last modified at [$Date: 2002/10/01 13:28:31 $]

DEFERRRED FOR APACHE 2.1

* Source code should follow style guidelines.

OK, we all agree pretty code is good. Probably best to clean this

up by hand immediately upon branching a 2.1 tree.

Status: Justin volunteers to hand-edit the entire source tree ;)

Justin says:

Recall when the release plan for 2.0 was written:

Absolute Enforcement of an "Apache Style" for code.

Watch this slip into 3.0.

David says:

The style guide needs to be reviewed before this can be done.

http://httpd.apache.org/dev/styleguide.html

The current file is dated April 20th 1998!

OtherBill offers:

It's survived since '98 because it's welldone :-) Suggest we

simply follow whatever is documented in styleguide.html as we

branch the next tree. Really sort of straightforward, if you

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.

* 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

that file, and allow the cleanup to close it [if it isn't a shared,

cached file handle.]

* The Async Apache Server implemented in terms of APR.

[Bill Stoddard's pet project.]

Message-ID: <008301c17d42$9b446970$01000100@sashimi> (dev@apr)

OtherBill notes that this can proceed in two parts...

Async accept, setup, and tear-down of the request

e.g. dealing with the incoming request headers, prior to

dispatching the request to a thread for processing.

This doesn't need to wait for a 2.x/3.0 bump.

Async delegation of the entire request processing chain

Too many handlers use stack storage and presume it is

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?

MAKING APACHE REPOSITORY-AGNOSTIC

(or: remove knowledge of the filesystem)

[ 2002/10/01: discussion in progress on items below; this isn't

planned yet ]

* dav_resource concept for an HTTP resource ("ap_resource")

* r->filename, r->canonical_filename, r->finfo need to

disappear. All users need to use new APIs on the ap_resource

object.

(backwards compat: today, when this occurs with mod_dav and a

custom backend, the above items refer to the topmost directory

mapped by a location; e.g. docroot)

* The translate_name hook goes away

* The doc for map_to_storage is totally opaque to me. It has

something to do with filesystems, but it also talks about

security and per_dir_config and other stuff. I presume something

needs to happen there -- at least better doc.

* The directory_walk concept disappears. All configuration is

tagged to Locations. The "mod_filesystem" module might have some

internal concept of the same config appearing in multiple

places, but that is handled internally rather than by Apache

core.

* 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.

Something like:

typedef struct {

const char *name; /* name of this node relative to parent */

struct ap_conf_vector_t *locn_config;

apr_hash_t *children; /* NULL if no child configs */

} ap_locn_node;

The following config:

<Location /server-status>

SetHandler server-status

Order deny,allow

Deny from allo

Allow from 127.0.0.1

</Location>

Creates a node with name=="server_status", and the node is a

child of the "/" node. (hmm. node->name is redundant with the

hash key; maybe drop node->name)

In the config vector, mod_access has stored its Order, Deny, and

Allow configs. mod_core has stored the SetHandler.

During the Location walk, we merge the config vectors normally.

Note that an Alias simply associates a filesystem path (in

mod_filesystem) with that Location in the tree. Merging

continues with child locations, but a merge is never done

through filesystem locations. Config on a specific subdir needs

to be mapped back into the corresponding point in the Location

tree for proper merging.

* Config is parsed into a tree, as we did for the 2.0 timeframe,

but that tree is just a representation of the config (for

multiple runs and for in-memory manipulation and usage). It is

unrelated to the "Location tree".

* Calls to apr_file_io functions generally need to be replaced

with operations against the ap_resource. For example, rather

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

need to be converted to use these mechanisms so that their

functions will work on logical repositories rather than just

filesystems.