httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j..@hyperreal.org
Subject cvs commit: apache-1.3 STATUS
Date Tue, 07 Apr 1998 12:36:27 GMT
jim         98/04/07 05:36:27

  Modified:    .        STATUS
  Log:
  Why even bother... remove my votes and comments
  
  Revision  Changes    Path
  1.272     +4 -14     apache-1.3/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /export/home/cvs/apache-1.3/STATUS,v
  retrieving revision 1.271
  retrieving revision 1.272
  diff -u -r1.271 -r1.272
  --- STATUS	1998/04/07 06:59:03	1.271
  +++ STATUS	1998/04/07 12:36:26	1.272
  @@ -299,16 +299,16 @@
       * What prefixes to use for the renaming:
   
           - Apache provided general functions (e.g., ap_cpystrn)
  -            ap_xxx:    +1: Ken, Brian, Ralf, Martin, Paul, Roy, Jim, Randy
  +            ap_xxx:    +1: Ken, Brian, Ralf, Martin, Paul, Roy, Randy
   
           - Public API functions (e.g., palloc)
               ap_xxx:    +1: Ralf, Roy, Dean, Randy, Martin, Brian
  -            apapi_xxx: +1: Ken, Paul, Jim
  +            apapi_xxx: +1: Ken, Paul
   
           - Private functions which we can't make static (because of
             cross-object usage) but should be (e.g., new_connection)
               ap_xxx:    +1: Roy, Dean, Randy, Martin, Brian
  -            apx_xxx:   +1: Ralf, Jim
  +            apx_xxx:   +1: Ralf
               appri_xxx: +1: Paul, Ken
   
           - Public API module structure variables (e.g.,
  @@ -316,7 +316,7 @@
             mod_so, etc and have to be exported:
               ..._module:+1: Roy [status quo], Dean
               ap_xxx:    +1:
  -            apm_xxx:   +1: Ralf, Jim
  +            apm_xxx:   +1: Ralf
   
           Notes: 
               - Ralf: My opinion for my decisions are the following ones: 
  @@ -386,16 +386,6 @@
               - 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
  -	      isn't. In my mind, we should use prefixed not JUST
  -	      to prevent namespace collisions, but also to
  -	      "define" the type function. The very fact that we
  -	      _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
  
  
  

Mime
View raw message