brian 98/04/10 05:31:44
Modified: . STATUS
Log:
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/rename.cf 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 fnm.sh, 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.
