2555N/ALast modified at [$Date: 2002/10/28 07:37:29 $]
2555N/A * Source code should follow style guidelines.
2555N/A OK, we all agree pretty code is good. Probably best to clean this
830N/A up by hand immediately upon branching a 2.1 tree.
2555N/A Status: Justin volunteers to hand-edit the entire source tree ;)
2555N/A Recall when the release plan for 2.0 was written:
2555N/A Absolute Enforcement of an "Apache Style" for code.
2555N/A The style guide needs to be reviewed before this can be done.
2555N/A The current file is dated April 20th 1998!
2555N/A It's survived since '98 because it's welldone :-) Suggest we
2555N/A branch the next tree. Really sort of straightforward, if you
2555N/A dislike a bit within that doc, bring it up on the dev@httpd
2555N/A list prior to the next branch.
2555N/A So Bill sums up ... let's get the code cleaned up in CVS head.
2555N/A Remember, it just takes cvs diff -b (that is, --ignore-space-change)
830N/A to see the code changes and ignore that cruft. Get editing Justin :)
2555N/A * revamp the input filter syntax to provide for ordering of
2555N/A filters created with the Set{Input|Output}Filter and the
2555N/A Add{Input|Output}Filter directives. A 'relative to filterx'
2555N/A syntax is definately preferable.
830N/A * Platforms that do not support fork (primarily Win32 and AS/400)
2555N/A Architect start-up code that avoids initializing all the modules
2555N/A in the parent process on platforms that do not support fork.
2555N/A . Better yet - not only inform the startup of which phase it's in,
2555N/A but allow the parent 'process' to initialize shared memory, etc,
2555N/A and create a module-by-module stream to pass to the child, so the
2555N/A parent can actually arbitrate the important stuff.
2555N/A Justin, Ian, OtherBill all interested in this. Implies setting up
2555N/A the apr_file_t member in request_rec, and having all modules use
2555N/A that file, and allow the cleanup to close it [if it isn't a shared,
830N/A * The Async Apache Server implemented in terms of APR.
830N/A [Bill Stoddard's pet project.]
2555N/A Message-ID: <008301c17d42$9b446970$01000100@sashimi> (dev@apr)
2555N/A OtherBill notes that this can proceed in two parts...
2555N/A Async accept, setup, and tear-down of the request
2555N/A e.g. dealing with the incoming request headers, prior to
2555N/A dispatching the request to a thread for processing.
2555N/A This doesn't need to wait for a
2.x/3.0 bump.
2555N/A Async delegation of the entire request processing chain
2555N/A Too many handlers use stack storage and presume it is
2555N/A available for the life of the request, so a complete
2555N/A async implementation would need to happen 3.0 release.
2555N/A Brian notes that async writes will provide a bigger
2555N/A scalability win than async reads for most servers.
2555N/A as a next step. This should be relatively easy to
2555N/A model, but hand off each response brigade to a "completion
2555N/A thread" that multiplexes writes on many connections, so
2555N/A that the worker thread doesn't have to wait around for
2555N/A * Add a string "class" that combines a char* with a length
2555N/A and a reference count. This will help reduce the number
2555N/A of strlen and strdup operations during request processing.
2555N/A Including both the length and allocation will save us a ton
2555N/A of reallocation we do today, in terms of string manipulation.
2555N/A OtherBill asks if this is really an APR issue, not an HTTPD issue?
2555N/A Brian notes that the performance optimization work in 2.0
2555N/A has all but eliminated the original motiviation for this
2555N/A idea. The httpd doesn't spend that much time in strlen
2555N/AMAKING APACHE REPOSITORY-AGNOSTIC
2555N/A(or: remove knowledge of the filesystem)
2555N/A[ 2002/10/01: discussion in progress on items below; this isn't
2555N/A * dav_resource concept for an HTTP resource ("ap_resource")
2555N/A * r->filename, r->canonical_filename, r->finfo need to
2555N/A disappear. All users need to use new APIs on the ap_resource
2555N/A (backwards compat: today, when this occurs with mod_dav and a
2555N/A custom backend, the above items refer to the topmost directory
2555N/A Need to preserve a 'filename'-like string for mime-by-name
2555N/A sorts of operations. But this only needs to be the name itself
2555N/A Justin: Can we leverage the path info, or do we not trust the
2555N/A gstein: well, it isn't the "path info", but the actual URI of
2555N/A the resource. And of course we trust the user... that is
2555N/A the resource they requested.
2555N/A dav_resource->uri is the field you want. path_info might
2555N/A still exist, but that portion might be related to the
2555N/A CGI concept of "path translated" or some other further
2555N/A To continue, I would suggest that "path translated" and
2555N/A having *any* path info is Badness. It means that you did
2555N/A not fully resolve a resource for the given URI. The
2555N/A "abs_path" in a URI identifies a resource, and that
2555N/A should get fully resolved. None of this "resolve to
2555N/A <here> and then we have a magical second resolution
2555N/A (inside the CGI script)" or somesuch.
2555N/A Justin: Well, let's consider mod_mbox for a second. It is sort of
2555N/A a virtual filesystem in its own right - as it introduces
2555N/A it's own notion of a URI space, but it is intrinsically
2555N/A tied to the filesystem to do the lookups. But, for the
2555N/A portion that isn't resolved on the file system, it has
2555N/A its own addressing scheme. Do we need the ability to
2555N/A * The translate_name hook goes away
2555N/A Wrowe altogether disagrees. translate_name today even operates
2555N/A on URIs ... this mechansim needs to be preserved.
2555N/A * The doc for map_to_storage is totally opaque to me. It has
2555N/A something to do with filesystems, but it also talks about
2555N/A security and per_dir_config and other stuff. I presume something
2555N/A needs to happen there -- at least better doc.
2555N/A Wrowe agrees and will write it up.
2555N/A * The directory_walk concept disappears. All configuration is
2555N/A tagged to Locations. The "mod_filesystem" module might have some
2555N/A internal concept of the same config appearing in multiple
2555N/A places, but that is handled internally rather than by Apache
2555N/A Wrowe suggests this is wrong, instead it's private to filesystem
2555N/A requests, and is already invoked from map_to_storage, not the core
2555N/A handler. <Directory > and <Files > blocks are preserved as-is,
2555N/A but <Directory > sections become specific to the filesystem handler
2555N/A alone. Because alternate filesystem schemes could be loaded, this
2555N/A should be exposed, from the core, for other file-based stores to
2555N/A share. Consider an archive store where the layers become
2555N/A <Directory path> -> <Archive store> -> <File name>
2555N/A Justin: How do we map Directory entries to Locations?
2555N/A * The "Location tree" is an in-memory representation of the URL
2555N/A namespace. Nodes of the tree have configuration specific to that
2555N/A const char *name; /* name of this node relative to parent */
2555N/A struct ap_conf_vector_t *locn_config;
2555N/A apr_hash_t *children; /* NULL if no child configs */
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
* 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
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
* 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
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
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?