removed some of the debug logging and added author details
[httpd-crcsyncproxy.git] / ROADMAP
blob44de676798d4588765b9f2046c8cf3f8de70c31f
1 APACHE 2.x ROADMAP
2 ==================
3 Last modified at [$Date$]
6 WORKS IN PROGRESS
7 -----------------
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 ;)
14       Justin says:
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.
19       David says:
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!
24         OtherBill offers:
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     * Replace stat [deferred open] with open/fstat in directory_walk.
36       Justin, Ian, OtherBill all interested in this.  Implies setting up
37       the apr_file_t member in request_rec, and having all modules use
38       that file, and allow the cleanup to close it [if it isn't a shared,
39       cached file handle.]
41     * The Async Apache Server implemented in terms of APR.
42       [Bill Stoddard's pet project.]
43       Message-ID: <008301c17d42$9b446970$01000100@sashimi> (dev@apr)
45         OtherBill notes that this can proceed in two parts...
47            Async accept, setup, and tear-down of the request 
48            e.g. dealing with the incoming request headers, prior to
49            dispatching the request to a thread for processing.
50            This doesn't need to wait for a 2.x/3.0 bump.
52            Async delegation of the entire request processing chain
53            Too many handlers use stack storage and presume it is 
54            available for the life of the request, so a complete 
55            async implementation would need to happen 3.0 release.
57         Brian notes that async writes will provide a bigger
58         scalability win than async reads for most servers.
59         We may want to try a hybrid sync-read/async-write MPM
60         as a next step.  This should be relatively easy to
61         build: start with the current worker or leader/followers
62         model, but hand off each response brigade to a "completion
63         thread" that multiplexes writes on many connections, so
64         that the worker thread doesn't have to wait around for
65         the sendfile to complete.
68 MAKING APACHE REPOSITORY-AGNOSTIC
69 (or: remove knowledge of the filesystem)
71 [ 2002/10/01: discussion in progress on items below; this isn't
72   planned yet ]
74     * dav_resource concept for an HTTP resource ("ap_resource")
76     * r->filename, r->canonical_filename, r->finfo need to
77       disappear. All users need to use new APIs on the ap_resource
78       object.
79       
80       (backwards compat: today, when this occurs with mod_dav and a
81        custom backend, the above items refer to the topmost directory
82        mapped by a location; e.g. docroot)
84       Need to preserve a 'filename'-like string for mime-by-name
85       sorts of operations.  But this only needs to be the name itself
86       and not a full path.
88       Justin: Can we leverage the path info, or do we not trust the
89               user?
91       gstein: well, it isn't the "path info", but the actual URI of
92               the resource. And of course we trust the user... that is
93               the resource they requested.
94               
95               dav_resource->uri is the field you want. path_info might
96               still exist, but that portion might be related to the
97               CGI concept of "path translated" or some other further
98               resolution.
99               
100               To continue, I would suggest that "path translated" and
101               having *any* path info is Badness. It means that you did
102               not fully resolve a resource for the given URI. The
103               "abs_path" in a URI identifies a resource, and that
104               should get fully resolved. None of this "resolve to
105               <here> and then we have a magical second resolution
106               (inside the CGI script)" or somesuch.
107    
108       Justin: Well, let's consider mod_mbox for a second.  It is sort of
109               a virtual filesystem in its own right - as it introduces
110               it's own notion of a URI space, but it is intrinsically
111               tied to the filesystem to do the lookups.  But, for the
112               portion that isn't resolved on the file system, it has
113               its own addressing scheme.  Do we need the ability to
114               layer resolution?
116     * The translate_name hook goes away
118       Wrowe altogether disagrees.  translate_name today even operates
119       on URIs ... this mechansim needs to be preserved.
120     
121     * The doc for map_to_storage is totally opaque to me. It has
122       something to do with filesystems, but it also talks about
123       security and per_dir_config and other stuff. I presume something
124       needs to happen there -- at least better doc.
126       Wrowe agrees and will write it up.
128     * The directory_walk concept disappears. All configuration is
129       tagged to Locations. The "mod_filesystem" module might have some
130       internal concept of the same config appearing in multiple
131       places, but that is handled internally rather than by Apache
132       core.
134       Wrowe suggests this is wrong, instead it's private to filesystem
135       requests, and is already invoked from map_to_storage, not the core
136       handler.  <Directory > and <Files > blocks are preserved as-is,
137       but <Directory > sections become specific to the filesystem handler
138       alone.  Because alternate filesystem schemes could be loaded, this
139       should be exposed, from the core, for other file-based stores to 
140       share. Consider an archive store where the layers become 
141       <Directory path> -> <Archive store> -> <File name>
142    
143       Justin: How do we map Directory entries to Locations?
145     * The "Location tree" is an in-memory representation of the URL
146       namespace. Nodes of the tree have configuration specific to that
147       location in the namespace.
148       
149       Something like:
150       
151       typedef struct {
152           const char *name;  /* name of this node relative to parent */
154           struct ap_conf_vector_t *locn_config;
156           apr_hash_t *children; /* NULL if no child configs */
157       } ap_locn_node;
159       The following config:
160       
161       <Location /server-status>
162           SetHandler server-status
163           Order deny,allow
164           Deny from all
165           Allow from 127.0.0.1
166       </Location>
167       
168       Creates a node with name=="server_status", and the node is a
169       child of the "/" node. (hmm. node->name is redundant with the
170       hash key; maybe drop node->name)
171       
172       In the config vector, mod_access has stored its Order, Deny, and
173       Allow configs. mod_core has stored the SetHandler.
174       
175       During the Location walk, we merge the config vectors normally.
176       
177       Note that an Alias simply associates a filesystem path (in
178       mod_filesystem) with that Location in the tree. Merging
179       continues with child locations, but a merge is never done
180       through filesystem locations. Config on a specific subdir needs
181       to be mapped back into the corresponding point in the Location
182       tree for proper merging.
184     * Config is parsed into a tree, as we did for the 2.0 timeframe,
185       but that tree is just a representation of the config (for
186       multiple runs and for in-memory manipulation and usage). It is
187       unrelated to the "Location tree".
189     * Calls to apr_file_io functions generally need to be replaced
190       with operations against the ap_resource. For example, rather
191       than calling apr_dir_open/read/close(), a caller uses
192       resource->repos->get_children() or somesuch.
194       Note that things like mod_dir, mod_autoindex, and mod_negotation
195       need to be converted to use these mechanisms so that their
196       functions will work on logical repositories rather than just
197       filesystems.
199     * How do we handle CGI scripts?  Especially when the resource may
200       not be backed by a file?  Ideally, we should be able to come up
201       with some mechanism to allow CGIs to work in a
202       repository-independent manner.
204       - Writing the virtual data as a file and then executing it?
205       - Can a shell be executed in a streamy manner?  (Portably?)
206       - Have an 'execute_resource' hook/func that allows the
207         repository to choose its manner - be it exec() or whatever.
208         - Won't this approach lead to duplication of code?  Helper fns?
210       gstein: PHP, Perl, and Python scripts are nominally executed by
211               a filter inserted by mod_php/perl/python. I'd suggest
212               that shell/batch scripts are similar.
214               But to ask further: what if it is an executable
215               *program* rather than just a script? Do we yank that out
216               of the repository, drop it onto the filesystem, and run
217               it? eeewwwww...
218               
219               I'll vote -0.9 for CGIs as a filter. Keep 'em handlers.
221       Justin: So, do we give up executing CGIs from virtual repositories?
222               That seems like a sad tradeoff to make.  I'd like to have
223               my CGI scripts under DAV (SVN) control.
225     * How do we handle overlaying of Location and Directory entries?
226       Right now, we have a problem when /cgi-bin/ is ScriptAlias'd and
227       mod_dav has control over /.  Some people believe that /cgi-bin/
228       shouldn't be under DAV control, while others do believe it
229       should be.  What's the right strategy?