1APACHE 2.x ROADMAP 2================== 3Last modified at [$Date: 2005-03-14 05:24:22 +0000 (Mon, 14 Mar 2005) $] 4 5 6WORKS IN PROGRESS 7----------------- 8 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 ;) 13 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. 18 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! 23 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. 30 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 :) 34 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.] 40 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) 44 45 OtherBill notes that this can proceed in two parts... 46 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. 51 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. 56 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. 66 67 68MAKING APACHE REPOSITORY-AGNOSTIC 69(or: remove knowledge of the filesystem) 70 71[ 2002/10/01: discussion in progress on items below; this isn't 72 planned yet ] 73 74 * dav_resource concept for an HTTP resource ("ap_resource") 75 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) 83 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. 87 88 Justin: Can we leverage the path info, or do we not trust the 89 user? 90 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? 115 116 * The translate_name hook goes away 117 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. 125 126 Wrowe agrees and will write it up. 127 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. 133 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? 144 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 */ 153 154 struct ap_conf_vector_t *locn_config; 155 156 apr_hash_t *children; /* NULL if no child configs */ 157 } ap_locn_node; 158 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. 183 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". 188 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. 193 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. 198 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. 203 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? 209 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. 213 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. 220 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. 224 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? 230