granicus.if.org Git - apache/blob - ROADMAP

   1 APACHE 2.x ROADMAP:
   2
   3 Last modified at [$Date: 2002/10/01 19:13:06 $]
   4
   5 DEFERRRED FOR APACHE 2.1
   6
   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 ;)
  11
  12       Justin says:
  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.
  16
  17       David says:
  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!
  21
  22         OtherBill offers:
  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.
  28
  29
  30 WORKS IN PROGRESS (PERHAPS DEFERRED FOR 2.1 or 3.0)
  31
  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.
  36
  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.
  40
  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.
  45
  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,
  50       cached file handle.]
  51
  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)
  55
  56         OtherBill notes that this can proceed in two parts...
  57
  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.
  62
  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.
  67
  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.
  73
  74         OtherBill asks if this is really an APR issue, not an HTTPD issue?
  75
  76
  77 MAKING APACHE REPOSITORY-AGNOSTIC
  78 (or: remove knowledge of the filesystem)
  79
  80 [ 2002/10/01: discussion in progress on items below; this isn't
  81   planned yet ]
  82
  83     * dav_resource concept for an HTTP resource ("ap_resource")
  84
  85     * r->filename, r->canonical_filename, r->finfo need to
  86       disappear. All users need to use new APIs on the ap_resource
  87       object.
  88
  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)
  92
  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
  95       and not a full path.
  96
  97       Justin: Can we leverage the path info, or do we not trust the
  98               user?
  99
 100       gstein: well, it isn't the "path info", but the actual URI of
 101               the resource. And of course we trust the user... that is
 102               the resource they requested.
 103
 104               dav_resource->uri is the field you want. path_info might
 105               still exist, but that portion might be related to the
 106               CGI concept of "path translated" or some other further
 107               resolution.
 108
 109               To continue, I would suggest that "path translated" and
 110               having *any* path info is Badness. It means that you did
 111               not fully resolve a resource for the given URI. The
 112               "abs_path" in a URI identifies a resource, and that
 113               should get fully resolved. None of this "resolve to
 114               <here> and then we have a magical second resolution
 115               (inside the CGI script)" or somesuch.
 116
 117       Justin: Well, let's consider mod_mbox for a second.  It is sort of
 118               a virtual filesystem in its own right - as it introduces
 119               it's own notion of a URI space, but it is intrinsically
 120               tied to the filesystem to do the lookups.  But, for the
 121               portion that isn't resolved on the file system, it has
 122               its own addressing scheme.  Do we need the ability to
 123               layer resolution?
 124
 125     * The translate_name hook goes away
 126
 127       Wrowe altogether disagrees.  translate_name today even operates
 128       on URIs ... this mechansim needs to be preserved.
 129
 130     * The doc for map_to_storage is totally opaque to me. It has
 131       something to do with filesystems, but it also talks about
 132       security and per_dir_config and other stuff. I presume something
 133       needs to happen there -- at least better doc.
 134
 135       Wrowe agrees and will write it up.
 136
 137     * The directory_walk concept disappears. All configuration is
 138       tagged to Locations. The "mod_filesystem" module might have some
 139       internal concept of the same config appearing in multiple
 140       places, but that is handled internally rather than by Apache
 141       core.
 142
 143       Wrowe suggests this is wrong, instead it's private to filesystem
 144       requests, and is already invoked from map_to_storage, not the core
 145       handler.  <Directory > and <Files > blocks are preserved as-is,
 146       but <Directory > sections become specific to the filesystem handler
 147       alone.  Because alternate filesystem schemes could be loaded, this
 148       should be exposed, from the core, for other file-based stores to
 149       share. Consider an archive store where the layers become
 150       <Directory path> -> <Archive store> -> <File name>
 151
 152       Justin: How do we map Directory entries to Locations?
 153
 154     * The "Location tree" is an in-memory representation of the URL
 155       namespace. Nodes of the tree have configuration specific to that
 156       location in the namespace.
 157
 158       Something like:
 159
 160       typedef struct {
 161           const char *name;  /* name of this node relative to parent */
 162
 163           struct ap_conf_vector_t *locn_config;
 164
 165           apr_hash_t *children; /* NULL if no child configs */
 166       } ap_locn_node;
 167
 168       The following config:
 169
 170       <Location /server-status>
 171           SetHandler server-status
 172           Order deny,allow
 173           Deny from all
 174           Allow from 127.0.0.1
 175       </Location>
 176
 177       Creates a node with name=="server_status", and the node is a
 178       child of the "/" node. (hmm. node->name is redundant with the
 179       hash key; maybe drop node->name)
 180
 181       In the config vector, mod_access has stored its Order, Deny, and
 182       Allow configs. mod_core has stored the SetHandler.
 183
 184       During the Location walk, we merge the config vectors normally.
 185
 186       Note that an Alias simply associates a filesystem path (in
 187       mod_filesystem) with that Location in the tree. Merging
 188       continues with child locations, but a merge is never done
 189       through filesystem locations. Config on a specific subdir needs
 190       to be mapped back into the corresponding point in the Location
 191       tree for proper merging.
 192
 193     * Config is parsed into a tree, as we did for the 2.0 timeframe,
 194       but that tree is just a representation of the config (for
 195       multiple runs and for in-memory manipulation and usage). It is
 196       unrelated to the "Location tree".
 197
 198     * Calls to apr_file_io functions generally need to be replaced
 199       with operations against the ap_resource. For example, rather
 200       than calling apr_dir_open/read/close(), a caller uses
 201       resource->repos->get_children() or somesuch.
 202
 203       Note that things like mod_dir, mod_autoindex, and mod_negotation
 204       need to be converted to use these mechanisms so that their
 205       functions will work on logical repositories rather than just
 206       filesystems.
 207
 208     * How do we handle CGI scripts?  Especially when the resource may
 209       not be backed by a file?  Ideally, we should be able to come up
 210       with some mechanism to allow CGIs to work in a
 211       repository-independent manner.
 212
 213       - Writing the virtual data as a file and then executing it?
 214       - Can a shell be executed in a streamy manner?  (Portably?)
 215       - Have an 'execute_resource' hook/func that allows the
 216         repository to choose its manner - be it exec() or whatever.
 217         - Won't this approach lead to duplication of code?  Helper fns?
 218
 219       gstein: PHP, Perl, and Python scripts are nominally executed by
 220               a filter inserted by mod_php/perl/python. I'd suggest
 221               that shell/batch scripts are similar.
 222
 223               But to ask further: what if it is an executable
 224               *program* rather than just a script? Do we yank that out
 225               of the repository, drop it onto the filesystem, and run
 226               it? eeewwwww...
 227
 228               I'll vote -0.9 for CGIs as a filter. Keep 'em handlers.
 229
 230       Justin: So, do we give up executing CGIs from virtual repositories?
 231               That seems like a sad tradeoff to make.  I'd like to have
 232               my CGI scripts under DAV (SVN) control.
 233
 234     * How do we handle overlaying of Location and Directory entries?
 235       Right now, we have a problem when /cgi-bin/ is ScriptAlias'd and
 236       mod_dav has control over /.  Some people believe that /cgi-bin/
 237       shouldn't be under DAV control, while others do believe it
 238       should be.  What's the right strategy?