3 Last modified at [$Date$]
9 * Source code should follow style guidelines.
10 OK, we all agree pretty code is good. Probably best to clean this
11 up by hand immediately upon branching a 2.1 tree.
12 Status: Justin volunteers to hand-edit the entire source tree ;)
15 Recall when the release plan for 2.0 was written:
16 Absolute Enforcement of an "Apache Style" for code.
17 Watch this slip into 3.0.
20 The style guide needs to be reviewed before this can be done.
21 http://httpd.apache.org/dev/styleguide.html
22 The current file is dated April 20th 1998!
25 It's survived since '98 because it's welldone :-) Suggest we
26 simply follow whatever is documented in styleguide.html as we
27 branch the next tree. Really sort of straightforward, if you
28 dislike a bit within that doc, bring it up on the dev@httpd
29 list prior to the next branch.
31 So Bill sums up ... let's get the code cleaned up in CVS head.
32 Remember, it just takes cvs diff -b (that is, --ignore-space-change)
33 to see the code changes and ignore that cruft. Get editing Justin :)
35 * revamp the input filter syntax to provide for ordering of
36 filters created with the Set{Input|Output}Filter and the
37 Add{Input|Output}Filter directives. A 'relative to filterx'
38 syntax is definately preferable.
40 * Platforms that do not support fork (primarily Win32 and AS/400)
41 Architect start-up code that avoids initializing all the modules
42 in the parent process on platforms that do not support fork.
44 . Better yet - not only inform the startup of which phase it's in,
45 but allow the parent 'process' to initialize shared memory, etc,
46 and create a module-by-module stream to pass to the child, so the
47 parent can actually arbitrate the important stuff.
49 * Replace stat [deferred open] with open/fstat in directory_walk.
50 Justin, Ian, OtherBill all interested in this. Implies setting up
51 the apr_file_t member in request_rec, and having all modules use
52 that file, and allow the cleanup to close it [if it isn't a shared,
55 * The Async Apache Server implemented in terms of APR.
56 [Bill Stoddard's pet project.]
57 Message-ID: <008301c17d42$9b446970$01000100@sashimi> (dev@apr)
59 OtherBill notes that this can proceed in two parts...
61 Async accept, setup, and tear-down of the request
62 e.g. dealing with the incoming request headers, prior to
63 dispatching the request to a thread for processing.
64 This doesn't need to wait for a 2.x/3.0 bump.
66 Async delegation of the entire request processing chain
67 Too many handlers use stack storage and presume it is
68 available for the life of the request, so a complete
69 async implementation would need to happen 3.0 release.
71 Brian notes that async writes will provide a bigger
72 scalability win than async reads for most servers.
73 We may want to try a hybrid sync-read/async-write MPM
74 as a next step. This should be relatively easy to
75 build: start with the current worker or leader/followers
76 model, but hand off each response brigade to a "completion
77 thread" that multiplexes writes on many connections, so
78 that the worker thread doesn't have to wait around for
79 the sendfile to complete.
81 * Add a string "class" that combines a char* with a length
82 and a reference count. This will help reduce the number
83 of strlen and strdup operations during request processing.
84 Including both the length and allocation will save us a ton
85 of reallocation we do today, in terms of string manipulation.
87 OtherBill asks if this is really an APR issue, not an HTTPD issue?
89 Brian notes that the performance optimization work in 2.0
90 has all but eliminated the original motiviation for this
91 idea. The httpd doesn't spend that much time in strlen
95 MAKING APACHE REPOSITORY-AGNOSTIC
96 (or: remove knowledge of the filesystem)
98 [ 2002/10/01: discussion in progress on items below; this isn't
101 * dav_resource concept for an HTTP resource ("ap_resource")
103 * r->filename, r->canonical_filename, r->finfo need to
104 disappear. All users need to use new APIs on the ap_resource
107 (backwards compat: today, when this occurs with mod_dav and a
108 custom backend, the above items refer to the topmost directory
109 mapped by a location; e.g. docroot)
111 Need to preserve a 'filename'-like string for mime-by-name
112 sorts of operations. But this only needs to be the name itself
115 Justin: Can we leverage the path info, or do we not trust the
118 gstein: well, it isn't the "path info", but the actual URI of
119 the resource. And of course we trust the user... that is
120 the resource they requested.
122 dav_resource->uri is the field you want. path_info might
123 still exist, but that portion might be related to the
124 CGI concept of "path translated" or some other further
127 To continue, I would suggest that "path translated" and
128 having *any* path info is Badness. It means that you did
129 not fully resolve a resource for the given URI. The
130 "abs_path" in a URI identifies a resource, and that
131 should get fully resolved. None of this "resolve to
132 <here> and then we have a magical second resolution
133 (inside the CGI script)" or somesuch.
135 Justin: Well, let's consider mod_mbox for a second. It is sort of
136 a virtual filesystem in its own right - as it introduces
137 it's own notion of a URI space, but it is intrinsically
138 tied to the filesystem to do the lookups. But, for the
139 portion that isn't resolved on the file system, it has
140 its own addressing scheme. Do we need the ability to
143 * The translate_name hook goes away
145 Wrowe altogether disagrees. translate_name today even operates
146 on URIs ... this mechansim needs to be preserved.
148 * The doc for map_to_storage is totally opaque to me. It has
149 something to do with filesystems, but it also talks about
150 security and per_dir_config and other stuff. I presume something
151 needs to happen there -- at least better doc.
153 Wrowe agrees and will write it up.
155 * The directory_walk concept disappears. All configuration is
156 tagged to Locations. The "mod_filesystem" module might have some
157 internal concept of the same config appearing in multiple
158 places, but that is handled internally rather than by Apache
161 Wrowe suggests this is wrong, instead it's private to filesystem
162 requests, and is already invoked from map_to_storage, not the core
163 handler. <Directory > and <Files > blocks are preserved as-is,
164 but <Directory > sections become specific to the filesystem handler
165 alone. Because alternate filesystem schemes could be loaded, this
166 should be exposed, from the core, for other file-based stores to
167 share. Consider an archive store where the layers become
168 <Directory path> -> <Archive store> -> <File name>
170 Justin: How do we map Directory entries to Locations?
172 * The "Location tree" is an in-memory representation of the URL
173 namespace. Nodes of the tree have configuration specific to that
174 location in the namespace.
179 const char *name; /* name of this node relative to parent */
181 struct ap_conf_vector_t *locn_config;
183 apr_hash_t *children; /* NULL if no child configs */
186 The following config:
188 <Location /server-status>
189 SetHandler server-status
195 Creates a node with name=="server_status", and the node is a
196 child of the "/" node. (hmm. node->name is redundant with the
197 hash key; maybe drop node->name)
199 In the config vector, mod_access has stored its Order, Deny, and
200 Allow configs. mod_core has stored the SetHandler.
202 During the Location walk, we merge the config vectors normally.
204 Note that an Alias simply associates a filesystem path (in
205 mod_filesystem) with that Location in the tree. Merging
206 continues with child locations, but a merge is never done
207 through filesystem locations. Config on a specific subdir needs
208 to be mapped back into the corresponding point in the Location
209 tree for proper merging.
211 * Config is parsed into a tree, as we did for the 2.0 timeframe,
212 but that tree is just a representation of the config (for
213 multiple runs and for in-memory manipulation and usage). It is
214 unrelated to the "Location tree".
216 * Calls to apr_file_io functions generally need to be replaced
217 with operations against the ap_resource. For example, rather
218 than calling apr_dir_open/read/close(), a caller uses
219 resource->repos->get_children() or somesuch.
221 Note that things like mod_dir, mod_autoindex, and mod_negotation
222 need to be converted to use these mechanisms so that their
223 functions will work on logical repositories rather than just
226 * How do we handle CGI scripts? Especially when the resource may
227 not be backed by a file? Ideally, we should be able to come up
228 with some mechanism to allow CGIs to work in a
229 repository-independent manner.
231 - Writing the virtual data as a file and then executing it?
232 - Can a shell be executed in a streamy manner? (Portably?)
233 - Have an 'execute_resource' hook/func that allows the
234 repository to choose its manner - be it exec() or whatever.
235 - Won't this approach lead to duplication of code? Helper fns?
237 gstein: PHP, Perl, and Python scripts are nominally executed by
238 a filter inserted by mod_php/perl/python. I'd suggest
239 that shell/batch scripts are similar.
241 But to ask further: what if it is an executable
242 *program* rather than just a script? Do we yank that out
243 of the repository, drop it onto the filesystem, and run
246 I'll vote -0.9 for CGIs as a filter. Keep 'em handlers.
248 Justin: So, do we give up executing CGIs from virtual repositories?
249 That seems like a sad tradeoff to make. I'd like to have
250 my CGI scripts under DAV (SVN) control.
252 * How do we handle overlaying of Location and Directory entries?
253 Right now, we have a problem when /cgi-bin/ is ScriptAlias'd and
254 mod_dav has control over /. Some people believe that /cgi-bin/
255 shouldn't be under DAV control, while others do believe it
256 should be. What's the right strategy?
projects / apache / blob