httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: apache-1.3 STATUS
Date Fri, 10 Apr 1998 12:31:44 GMT
brian       98/04/10 05:31:44

  Modified:    .        STATUS
  Consensus reached.  Comments on the vote will be kept in the CVS logs of course.
  Revision  Changes    Path
  1.289     +5 -95     apache-1.3/STATUS
  Index: STATUS
  RCS file: /export/home/cvs/apache-1.3/STATUS,v
  retrieving revision 1.288
  retrieving revision 1.289
  diff -u -r1.288 -r1.289
  --- STATUS	1998/04/10 10:41:13	1.288
  +++ STATUS	1998/04/10 12:31:43	1.289
  @@ -190,106 +190,16 @@
   Closed issues:
  -Open issues:
  -    * 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/ file as the configuration for the
  -      renaming. The used prefix or prefixes are configureable in the file.
  -       +1:
  -        0: Ralf, Marc
  -      Notes:
  -       - Marc: this is the wrong time for such a big change
  -    * What prefixes to use for the renaming:
  +    * To avoid symbol clashes with third-party code compiled into the server,
  +      we shall apply the prefix "ap_" to the following classes of functions:
           - Apache provided general functions (e.g., ap_cpystrn)
  -	    ap_xxx:    +1: Ken, Brian, Ralf, Paul, Randy
  -	- Public API functions (e.g., palloc, bgets)
  -            ap_xxx:    +1: Ralf, Randy, Martin, Brian, Paul
  +        - Public API functions (e.g., palloc, bgets)
           - Private functions which we can't make static (because of
             cross-object usage) but should be (e.g., new_connection)
  -	    ap_xxx:    +1: Randy, Brian, Paul, Ralf
  -        Notes: 
  -	    - Ken: Veto rescinded.
  -            - Ralf: My opinion for my decisions are the following ones: 
  -              1. The short ap_ prefix is a good idea because its
  -                 a handy prefix while still Apache specific, so I
  -                 would use it for those symbols we deal most: API
  -                 symbols.
  -              2. There is a distinction needed between symbols 
  -                 we want explicitly export (API) and those we are
  -                 forced to export (cross-object references).
  -                 Hence a the apx_ prefix. It's different from ap_
  -                 but as short as it can while still providing the
  -                 needed information: "ap" for Apache and "x" for
  -                 internal cross-object symbol.
  -              3. When you are look at the code you notice that 
  -                 we use <name>_module for the names of the
  -                 module's dispatch structure. First, it always
  -                 was confusing in the past that a module named
  -                 mod_abc_def usually had a def_abc_module symbol
  -                 (e.g. mod_auth variants). Second the
  -                 src/Configure stuff has great guessing problems
  -                 due to this difference. Third, mod_so has
  -                 resolving problems. Fourth, the user who used
  -                 the "LoadModule" directive has the most
  -                 problems, because he had to write down the
  -                 correct symbol name. Fifth, the names
  -                 xxxx_module are too generic that we can keep
  -                 them while we rename all others. They need also
  -                 a renaming to be Apache specific. So, to make
  -                 them Apache specific, solve the confusion _AND_
  -                 mark them special because of shared object
  -                 loading, I propose apm_ as the prefix, i.e.
  -                 name1_module bekomes apm_name1. That's short,
  -                 Apache specific and indicates (the "m") that
  -                 this is a module's bootstrap symbol. This
  -                 simplifies mod_so's LoadModule, src/Configure,
  -                 APACI's, etc. and makes less confusion to
  -                 the user while still providing the private
  -                 symbolspace.
  -            - Randy: I agree with Dean 100%. The work created to
  -              keep this straight far outweighs any gain this
  -              could give. 
  -            - 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
  -              distinction is really needed. At least between
  -              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).
  -	    - Martin:
  -	      As a high priority item, *ALL* clashes with system functions
  -	      should be avoided if at all possible. Even names like bgets()
  -	      are ``in use'' by SVR4 and should be prefixed.
  -	      The next priority level is a *documented* API (thanks for
  -	      the beginnings of that, Ken!) which should IMO offer ap_*
  -	      functions only.
  -	      Then there's our libap approach which can best be realized by
  -	      prefixing the functions to show where they belong.
  -	      And finally, there's all the "private" glue that keeps the
  -	      core together (and I don't really care if it has prefixes
  -	      as long as there are no name clashes with 3rd party things).
  +Open issues:
       * Paul would like to see a 'gdbm' option because he uses
         it a lot.

View raw message