httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From field...@hyperreal.org
Subject cvs commit: apache-1.3 STATUS
Date Tue, 07 Apr 1998 01:26:39 GMT
fielding    98/04/06 18:26:39

  Modified:    .        STATUS
  Log:
  A good way to ensure that we never come to a decision is to change
  the voting options without carrying-over the votes already cast,
  as was done when this was split into mutually contradictory alternatives.
  Merge them together so people can see what is the actual status.
  
  Revision  Changes    Path
  1.267     +38 -27    apache-1.3/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /home/cvs/apache-1.3/STATUS,v
  retrieving revision 1.266
  retrieving revision 1.267
  diff -u -r1.266 -r1.267
  --- STATUS	1998/04/06 08:31:40	1.266
  +++ STATUS	1998/04/07 01:26:38	1.267
  @@ -153,7 +153,13 @@
   
       * The proposed steps for the big symbol renaming change:
   
  +      NOTE: Roy won't even start down this path until there is at least
  +            three +1 votes for the prefix option(s) applied (see below).
  +
         Step 1: Roy
  +        - completely remove HIDE stuff from
  +             src/Configure, include/*, APACI, etc.
  +
           - tag the source tree
             $ cd apache-1.3
             $ cvs tag PRE_AP_PREFIX_RENAME .
  @@ -164,7 +170,6 @@
             $ cd apache-1.3
             $ ./configure --prefix=/tmp/apache 
                           --enable-module=most
  -                        --disable-rule=HIDE
           - check symbols
             $ cd apache-1.3/src
             $ nm -g httpd |more
  @@ -177,7 +182,6 @@
             $ ./configure --prefix=/tmp/apache 
                           --enable-module=most
                           --enable-shared=max
  -                        --disable-rule=HIDE
           - check symbols
             $ cd apache-1.3/src
             $ nm -g httpd | egrep -v '_modules?$' | egrep -v 'apx?_' | grep -v '.o$'
  @@ -204,12 +208,12 @@
                the prefix in rename.cf) and adjust/simplify src/Configure,
                mod_so.c accordingly etc. These APM_ symbols were commented
                in rename.cf for Roys step.
  +             [Roy doesn't think this step is necessary]
             2. change the prelinked_modules and preloaded_modules symbols
                to APX_ variants manually and adjust src/Configure accordingly.
                These APX_ symbols were commented in rename.cf for Roys step
                because these cannot be done automatically.
  -          3. completely remove HIDE stuff because that's now obsolete:
  -             src/Configure, include/*, APACI, etc.
  +             [Roy might do this himself if the changes are clear]
           - compile entire server (static variant)
             $ cd apache-1.3
             $ ./configure --prefix=/tmp/apache 
  @@ -273,30 +277,31 @@
       * Cleanup the symbol space now in the source for 
         1.3b6 and thus for the 1.3.x release branch via the
         apache-1.3/src/test/rename/rename.cf file as the configuration for the
  -      renaming. The used prefix or prefixes are configureable in the file,
  -      too. But we have to additionally vote on them in the next point.
  -      Votes: +1: Ralf, Jim, Roy
  -              0: Marc
  +      renaming. The used prefix or prefixes are configureable in the file.
  +       +1: Ralf, Jim, Roy
  +        0: Marc [thinks this is the wrong time for such a big change]
   
  -    * Use consistant prefixes for the renaming; suggestions:
  +    * What prefixes to use for the renaming:
   
  -      o Different prefixes to distinguish between 
  -        the type of functions:
  -
           - Apache provided general functions (e.g., ap_cpystrn)
  -            ap_xxx: +0: Ken, Brian, Ralf, Martin, Paul, Roy, Jim
  +            ap_xxx:    +1: Ken, Brian, Ralf, Martin, Paul, Roy, Jim, Randy
  +
           - Public API functions (e.g., palloc)
  -            ap_xxx: +1 Ralf, Roy
  +            ap_xxx:    +1: Ralf, Roy, Dean, Randy, Martin, Brian
               apapi_xxx: +1: Ken, Paul, Jim
  +
           - Private functions which we can't make static (because of
             cross-object usage) but should be (e.g., new_connection)
  -            apx_xxx +1: Ralf, Roy, Jim
  -            appri_xxx +1: Paul, Ken
  +            ap_xxx:    +1: Roy, Dean, Randy, Martin, Brian
  +            apx_xxx:   +1: Ralf, Roy, Jim
  +            appri_xxx: +1: Paul, Ken
  +
           - Public API module structure variables (e.g.,
             status_module) which are used special in Configure,
             mod_so, etc and have to be exported:
  -            ap_xxx +1:
  -            apm_xxx +1: Ralf, Roy, Jim
  +            ..._module:+1: Roy [status quo] 
  +            ap_xxx:    +1:
  +            apm_xxx:   +1: Ralf, Jim
   
           Notes: 
               - Ralf: My opinion for my decisions are the following ones: 
  @@ -337,22 +342,17 @@
                    the user while still providing the private
                    symbolspace.
                    
  -      o Alternate proposal:
  -        Everything should be prefixes with just ap_:
  -        Votes: +1: Dean, Randy, Roy, Martin, Brian
  -               +0: Ralf
  -               -1: Jim
  -
  -        Notes: 
  -            - Dean: Why? Because it's far easier to type, and damn
  -              it, I type these things far too much.  Just using
  +            - Dean: [Use ap_ only] Why? Because it's far easier to type,
  +              and damn it, I type these things far too much.  Just using
                 apapi_ for the few hours I did while writing
                 apapi_vformatter is making me puke.  So many extra
                 characters, so much wasted screen width, and
                 keystrokes.
  +
               - Randy: I agree with Dean 100%. The work created to
                 keep this straight far outweighs any gain this
                 could give. 
  +
               - Jim: We should make some sort of logical effort to
                 keep things straight and organized. This does nothing
   	      to indicate in the code what is API, and what
  @@ -362,6 +362,7 @@
   	      _have_ the above different "types" of functions
   	      indicates to me that we should have some logical
   	      namespace for them.
  +
               - Ralf: I agree with Jim that although the short ap_
                 prefix is good for API functions, it shouldn't be
                 used for all functions. That's too less. Some
  @@ -369,6 +370,16 @@
                 really exported symbols (API) and symbols which are
                 just forced to be exported due to the way the
                 linker works (internal cross-object references)
  +
  +            - Roy: A prefix should only be significant in the sense that
  +              it allows us to avoid symbol conflicts.  Within our own
  +              symbol set, we always want to use the same prefix because
  +              it allows us to more easily move functions from non-API to
  +              API areas, and because it prevents the nasty situation of
  +              having both an ap_foo_bar and apapi_foo_bar.  It also reduces
  +              the mental gymnastics necessary when anticipating a function
  +              name (i.e., if everything is ap_, the prefix fades into the
  +              background of our cognitive model of the source code).
   
       * Paul would like to see a 'gdbm' option because he uses
         it a lot. Dean notes that 'gdbm' include 'db' support
  
  
  

Mime
View raw message