8af80418ba1ec431c8027fa9668e5678658d3611Allan FosterAPACHE 2.x ROADMAP:

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan FosterLast modified at [$Date: 2002/10/01 16:51:10 $]

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan FosterDEFERRRED FOR APACHE 2.1

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster * Source code should follow style guidelines.

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

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster up by hand immediately upon branching a 2.1 tree.

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

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster Justin says:

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster Recall when the release plan for 2.0 was written:

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster Absolute Enforcement of an "Apache Style" for code.

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster Watch this slip into 3.0.

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster David says:

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

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster http://httpd.apache.org/dev/styleguide.html

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster The current file is dated April 20th 1998!

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster OtherBill offers:

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

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster simply follow whatever is documented in styleguide.html as we

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

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster dislike a bit within that doc, bring it up on the dev@httpd

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster list prior to the next branch.

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan FosterWORKS IN PROGRESS (PERHAPS DEFERRED FOR 2.1 or 3.0)

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster * revamp the input filter syntax to provide for ordering of

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster filters created with the Set{Input|Output}Filter and the

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster Add{Input|Output}Filter directives. A 'relative to filterx'

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster syntax is definately preferable.

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster * Platforms that do not support fork (primarily Win32 and AS/400)

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster Architect start-up code that avoids initializing all the modules

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster in the parent process on platforms that do not support fork.

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster . Better yet - not only inform the startup of which phase it's in,

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster but allow the parent 'process' to initialize shared memory, etc,

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster and create a module-by-module stream to pass to the child, so the

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster parent can actually arbitrate the important stuff.

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster * Replace stat [deferred open] with open/fstat in directory_walk.

8af80418ba1ec431c8027fa9668e5678658d3611Allan Foster 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)

Need to preserve a 'filename'-like string for mime-by-name

sorts of operations. But this only needs to be the name itself

and not a full path.

Justin: Can we leverage the path info, or do we not trust the

user?

gstein: well, it isn't the "path info", but the actual URI of

the resource. And of course we trust the user... that is

the resource they requested.

dav_resource->uri is the field you want. path_info might

still exist, but that portion might be related to the

CGI concept of "path translated" or some other further

resolution.

To continue, I would suggest that "path translated" and

having *any* path info is Badness. It means that you did

not fully resolve a resource for the given URI. The

"abs_path" in a URI identifies a resource, and that

should get fully resolved. None of this "resolve to

<here> and then we have a magical second resolution

(inside the CGI script)" or somesuch.

* The translate_name hook goes away

Wrowe altogether disagrees. translate_name today even operates

on URIs ... this mechansim needs to be preserved.

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

Wrowe agrees and will write it up.

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

Wrowe suggests this is wrong, instead it's private to filesystem

requests, and is already invoked from map_to_storage, not the core

handler. <Directory > and <Files > blocks are preserved as-is,

but <Directory > sections become specific to the filesystem handler

alone. Because alternate filesystem schemes could be loaded, this

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>

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

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.

* How do we handle CGI scripts? Especially when the resource may

not be backed by a file? Ideally, we should be able to come up

with some mechanism to allow CGIs to work in a

repository-independent manner.

- Writing the virtual data as a file and then executing it?

- Can a shell be executed in a streamy manner? (Portably?)

- Have an 'execute_resource' hook/func that allows the

repository to choose its manner - be it exec() or whatever.

- Won't this approach lead to duplication of code? Helper fns?

gstein: PHP, Perl, and Python scripts are nominally executed by

a filter inserted by mod_php/perl/python. I'd suggest

that shell/batch scripts are similar.

But to ask further: what if it is an executable

*program* rather than just a script? Do we yank that out

of the repository, drop it onto the filesystem, and run

it? eeewwwww...

I'll vote -0.9 for CGIs as a filter. Keep 'em handlers.