rse 98/04/02 23:59:28
Modified: . STATUS
Log:
Cleanup the two "symbol rename" and "prefix" debates for a clear voting.
They are different:
1. Please give your vote to the "symbol rename" issue about the fact whether
we now really should solve the problem by renaming the source or not (can
be automatically done by the src/test/rename/ stuff).
2. Please give your vote to the "prefix" issue for the general fact about
which
prefix we really want. Either for the symbol renaming above (for 1.3) or at
least for the new Apache 2.0.
Revision Changes Path
1.255 +99 -38 apache-1.3/STATUS
Index: STATUS
===================================================================
RCS file: /export/home/cvs/apache-1.3/STATUS,v
retrieving revision 1.254
retrieving revision 1.255
diff -u -r1.254 -r1.255
--- STATUS 1998/04/03 00:32:45 1.254
+++ STATUS 1998/04/03 07:59:27 1.255
@@ -169,45 +169,106 @@
Closed issues:
Open issues:
-
- * Provide consistant prefixes; suggestions:
-
- Apache provided general functions (e.g., ap_cpystrn)
- ap_xxx: +1: Ken, Brian, Ralf, Martin, Paul, Roy, Jim
-
- Public API functions (e.g., palloc)
- apapi_xxx: +1: Ken, Ralf, Paul, Jim
- appublic_xxx:
- appub_xxx:
-
- Private functions which we can't make static
- but should be (e.g., new_connection)
- apprivate_xxx:
- appri_xxx: +1: Paul, Jim, Ken
- httpd_xxx: +1:
- apint_xxx: +1: Ralf (int = internal)
- Alternate proposal:
- Everything should be ap_: +1 Dean, Randy, Roy, Martin
- 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. -Dean
- +1 Brian
-
- I agree with Dean 100%. The work created to keep this straight
- far outweighs any gain this could give. -Randy
-
- -1: Jim. We should make some sort of logical effort to
- keep things straight and organized. Taken to it's logical
- conclusion, this argument could be used to keep all variable
- and function names to 6 chars or less to cut down on all
- that nasty typing. So instead of something like
- 'lingering_close', we would use something like 'lcs' :)
- We should make some effort to make our code reader and
- maintainer friendly, because we aren't, and won't be,
- the only one's to maintain this.
+ * 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: Ralf +1
+
+ * Use consistant prefixes for the renaming; suggestions:
+
+ 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
+ - Public API functions (e.g., palloc)
+ ap_xxx: +1 Ralf
+ 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
+ appri_xxx +1: Paul, Jim, 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
+
+ Notes:
+ - 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 fnm.sh, etc. and makes less confusion to
+ 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
+ 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. Taken to it's
+ logical conclusion, this argument could be used to
+ keep all variable and function names to 6 chars or
+ less to cut down on all that nasty typing. So
+ instead of something like 'lingering_close', we
+ would use something like 'lcs' :) We should make
+ some effort to make our code reader and maintainer
+ friendly, because we aren't, and won't be, the only
+ one's to maintain this.
+ - 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)
* Paul would like to see a 'gdbm' option because he uses
it a lot. Dean notes that 'gdbm' include 'db' support
