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
