3 Last modified at [$Date: 2002/10/01 15:26:20 $]
5 DEFERRRED FOR APACHE 2.1
7 * Source code should follow style guidelines.
8 OK, we all agree pretty code is good. Probably best to clean this
9 up by hand immediately upon branching a 2.1 tree.
10 Status: Justin volunteers to hand-edit the entire source tree ;)
13 Recall when the release plan for 2.0 was written:
14 Absolute Enforcement of an "Apache Style" for code.
15 Watch this slip into 3.0.
18 The style guide needs to be reviewed before this can be done.
19 http://httpd.apache.org/dev/styleguide.html
20 The current file is dated April 20th 1998!
23 It's survived since '98 because it's welldone :-) Suggest we
24 simply follow whatever is documented in styleguide.html as we
25 branch the next tree. Really sort of straightforward, if you
26 dislike a bit within that doc, bring it up on the dev@httpd
27 list prior to the next branch.
30 WORKS IN PROGRESS (PERHAPS DEFERRED FOR 2.1 or 3.0)
32 * revamp the input filter syntax to provide for ordering of
33 filters created with the Set{Input|Output}Filter and the
34 Add{Input|Output}Filter directives. A 'relative to filterx'
35 syntax is definately preferable.
37 * Platforms that do not support fork (primarily Win32 and AS/400)
38 Architect start-up code that avoids initializing all the modules
39 in the parent process on platforms that do not support fork.
41 . Better yet - not only inform the startup of which phase it's in,
42 but allow the parent 'process' to initialize shared memory, etc,
43 and create a module-by-module stream to pass to the child, so the
44 parent can actually arbitrate the important stuff.
46 * Replace stat [deferred open] with open/fstat in directory_walk.
47 Justin, Ian, OtherBill all interested in this. Implies setting up
48 the apr_file_t member in request_rec, and having all modules use
49 that file, and allow the cleanup to close it [if it isn't a shared,
52 * The Async Apache Server implemented in terms of APR.
53 [Bill Stoddard's pet project.]
54 Message-ID: <008301c17d42$9b446970$01000100@sashimi> (dev@apr)
56 OtherBill notes that this can proceed in two parts...
58 Async accept, setup, and tear-down of the request
59 e.g. dealing with the incoming request headers, prior to
60 dispatching the request to a thread for processing.
61 This doesn't need to wait for a 2.x/3.0 bump.
63 Async delegation of the entire request processing chain
64 Too many handlers use stack storage and presume it is
65 available for the life of the request, so a complete
66 async implementation would need to happen 3.0 release.
68 * Add a string "class" that combines a char* with a length
69 and a reference count. This will help reduce the number
70 of strlen and strdup operations during request processing.
71 Including both the length and allocation will save us a ton
72 of reallocation we do today, in terms of string manipulation.
74 OtherBill asks if this is really an APR issue, not an HTTPD issue?
77 MAKING APACHE REPOSITORY-AGNOSTIC
78 (or: remove knowledge of the filesystem)
80 [ 2002/10/01: discussion in progress on items below; this isn't
83 * dav_resource concept for an HTTP resource ("ap_resource")
85 * r->filename, r->canonical_filename, r->finfo need to
86 disappear. All users need to use new APIs on the ap_resource
89 (backwards compat: today, when this occurs with mod_dav and a
90 custom backend, the above items refer to the topmost directory
91 mapped by a location; e.g. docroot)
93 Need to preserve a 'filename'-like string for mime-by-name
94 sorts of operations. But this only needs to be the name itself
97 * The translate_name hook goes away
99 Wrowe altogether disagrees. translate_name today even operates
100 on URIs ... this mechansim needs to be preserved.
102 * The doc for map_to_storage is totally opaque to me. It has
103 something to do with filesystems, but it also talks about
104 security and per_dir_config and other stuff. I presume something
105 needs to happen there -- at least better doc.
107 Wrowe agrees and will write it up.
109 * The directory_walk concept disappears. All configuration is
110 tagged to Locations. The "mod_filesystem" module might have some
111 internal concept of the same config appearing in multiple
112 places, but that is handled internally rather than by Apache
115 Wrowe suggests this is wrong, instead it's private to filesystem
116 requests, and is already invoked from map_to_storage, not the core
117 handler. <Directory > and <Files > blocks are preserved as-is,
118 but <Directory > sections become specific to the filesystem handler
119 alone. Because alternate filesystem schemes could be loaded, this
120 should be exposed, from the core, for other file-based stores to
121 share. Consider an archive store where the layers become
122 <Directory path> -> <Archive store> -> <File name>
124 * The "Location tree" is an in-memory representation of the URL
125 namespace. Nodes of the tree have configuration specific to that
126 location in the namespace.
131 const char *name; /* name of this node relative to parent */
133 struct ap_conf_vector_t *locn_config;
135 apr_hash_t *children; /* NULL if no child configs */
138 The following config:
140 <Location /server-status>
141 SetHandler server-status
147 Creates a node with name=="server_status", and the node is a
148 child of the "/" node. (hmm. node->name is redundant with the
149 hash key; maybe drop node->name)
151 In the config vector, mod_access has stored its Order, Deny, and
152 Allow configs. mod_core has stored the SetHandler.
154 During the Location walk, we merge the config vectors normally.
156 Note that an Alias simply associates a filesystem path (in
157 mod_filesystem) with that Location in the tree. Merging
158 continues with child locations, but a merge is never done
159 through filesystem locations. Config on a specific subdir needs
160 to be mapped back into the corresponding point in the Location
161 tree for proper merging.
163 * Config is parsed into a tree, as we did for the 2.0 timeframe,
164 but that tree is just a representation of the config (for
165 multiple runs and for in-memory manipulation and usage). It is
166 unrelated to the "Location tree".
168 * Calls to apr_file_io functions generally need to be replaced
169 with operations against the ap_resource. For example, rather
170 than calling apr_dir_open/read/close(), a caller uses
171 resource->repos->get_children() or somesuch.
173 Note that things like mod_dir, mod_autoindex, and mod_negotation
174 need to be converted to use these mechanisms so that their
175 functions will work on logical repositories rather than just