httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mar...@hyperreal.org
Subject cvs commit: apache-1.3 STATUS
Date Thu, 09 Apr 1998 14:33:08 GMT
martin      98/04/09 07:33:08

  Modified:    .        STATUS
  Log:
  Updates & Votes
  
  Revision  Changes    Path
  1.286     +30 -15    apache-1.3/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /home/cvs/apache-1.3/STATUS,v
  retrieving revision 1.285
  retrieving revision 1.286
  diff -u -u -r1.285 -r1.286
  --- STATUS	1998/04/09 10:22:47	1.285
  +++ STATUS	1998/04/09 14:33:07	1.286
  @@ -164,19 +164,21 @@
   
   In progress:
   
  -    * Ralf's and Martin's enhancement to the DSO support in Apache
  -      to be able to support DSO under mostly all SVR4-variants, too. 
  -      This would be a major milestone for Apache's DSO support. It is done by
  +    * Ralf's and Martin's enhancement to the DSO support in Apache to be
  +      able to support DSO under mostly all SVR4 variants, too. This would
  +      be a major milestone for Apache's DSO support. It is done by
         providing a Configuration.tmpl Rule which builds Apache into its own
         libhttpd.so while the httpd program is just a stub. This implicitly
  -      makes DSO working under SVR4 because under this platform one cannot
  -      force the linker to export global symbols (to make them available to the
  -      DSO modules). But when Apache's core itself is in a shared object these
  -      symbols _are_ available. BINGO! A nice sideeffect is that the usage of a
  -      libhttpd.so can be nice under other platforms, too. Oh, BTW: This is the
  -      trick Perl 5 already does to support DSO under SVR4, i.e. the idea is
  -      just stolen from Perl 5 because this trick is the only portable way to
  -      provide DSO support for program extensions under SVR4 ;-)
  +      makes DSO working under SVR4 because under this platform there is no
  +      generally available compiler switch to force the linker to export
  +      global symbols (to make them available to the DSO modules). But when
  +      Apache's core itself is in a shared object these symbols _are_
  +      available. BINGO! A nice side effect is that the usage of a
  +      libhttpd.so can be nice under other platforms, too. Oh, BTW: This is
  +      the trick Perl 5 already does to support DSO under SVR4, i.e. the
  +      idea is just stolen from Perl 5 because this trick is the only
  +      portable way to provide DSO support for program extensions under
  +      SVR4 ;-)
         Patch from Ralf is coming in the next days!
   
       * Ken's IndexFormat enhancement to mod_autoindex to allow
  @@ -216,14 +218,14 @@
       * What prefixes to use for the renaming:
   
           - Apache provided general functions (e.g., ap_cpystrn)
  -            ap_xxx:    +1: Ken, Brian, Ralf, Martin, Paul, Randy
  +	    ap_xxx:    +1: Ken, Brian, Ralf, Paul, Randy
   
  -        - Public API functions (e.g., palloc)
  +	- Public API functions (e.g., palloc, bgets)
               ap_xxx:    +1: Ralf, Randy, Martin, Brian, Paul
   
           - Private functions which we can't make static (because of
             cross-object usage) but should be (e.g., new_connection)
  -            ap_xxx:    +1: Randy, Martin, Brian, Paul, Ralf
  +	    ap_xxx:    +1: Randy, Brian, Paul, Ralf
   
           Notes: 
   	    - Ken: Veto rescinded.
  @@ -288,6 +290,19 @@
                 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).
  +
       * Paul would like to see a 'gdbm' option because he uses
         it a lot.
   
  @@ -298,7 +313,7 @@
       * What do we call the binary: apache or httpd? Under UNIX
         it's httpd, under Win32 it's apache.
   	apache-httpd: Ken +1
  -        leave it apache: Brian +1, Ralf +1
  +	leave it apache: +1 Brian, Ralf, Martin
   
       * Maybe a http_paths.h file? See
   	<Pine.BSF.3.95q.971209222046.25627D-100000@valis.worldgate.com>
  
  
  

Mime
View raw message