httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerenkra...@apache.org
Subject cvs commit: httpd-2.0 ROADMAP
Date Tue, 01 Oct 2002 19:13:07 GMT
jerenkrantz    2002/10/01 12:13:07

  Modified:    .        ROADMAP
  Log:
  i was born a rambling man...
  
  Revision  Changes    Path
  1.16      +23 -3     httpd-2.0/ROADMAP
  
  Index: ROADMAP
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/ROADMAP,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -u -r1.15 -r1.16
  --- ROADMAP	1 Oct 2002 16:51:10 -0000	1.15
  +++ ROADMAP	1 Oct 2002 19:13:06 -0000	1.16
  @@ -113,7 +113,15 @@
                 should get fully resolved. None of this "resolve to
                 <here> and then we have a magical second resolution
                 (inside the CGI script)" or somesuch.
  -    
  +   
  +      Justin: Well, let's consider mod_mbox for a second.  It is sort of
  +              a virtual filesystem in its own right - as it introduces
  +              it's own notion of a URI space, but it is intrinsically
  +              tied to the filesystem to do the lookups.  But, for the
  +              portion that isn't resolved on the file system, it has
  +              its own addressing scheme.  Do we need the ability to
  +              layer resolution?
  +
       * The translate_name hook goes away
   
         Wrowe altogether disagrees.  translate_name today even operates
  @@ -140,7 +148,9 @@
         should be exposed, from the core, for other file-based stores to 
         share. Consider an archive store where the layers become 
         <Directory path> -> <Archive store> -> <File name>
  -    
  +   
  +      Justin: How do we map Directory entries to Locations?
  + 
       * The "Location tree" is an in-memory representation of the URL
         namespace. Nodes of the tree have configuration specific to that
         location in the namespace.
  @@ -216,3 +226,13 @@
                 it? eeewwwww...
                 
                 I'll vote -0.9 for CGIs as a filter. Keep 'em handlers.
  +
  +      Justin: So, do we give up executing CGIs from virtual repositories?
  +              That seems like a sad tradeoff to make.  I'd like to have
  +              my CGI scripts under DAV (SVN) control.
  +
  +    * How do we handle overlaying of Location and Directory entries?
  +      Right now, we have a problem when /cgi-bin/ is ScriptAlias'd and
  +      mod_dav has control over /.  Some people believe that /cgi-bin/
  +      shouldn't be under DAV control, while others do believe it
  +      should be.  What's the right strategy?
  
  
  

Mime
View raw message