jim 98/04/07 05:36:27
Modified: . STATUS
Log:
Why even bother... remove my votes and comments
Revision Changes Path
1.272 +4 -14 apache-1.3/STATUS
Index: STATUS
===================================================================
RCS file: /export/home/cvs/apache-1.3/STATUS,v
retrieving revision 1.271
retrieving revision 1.272
diff -u -r1.271 -r1.272
--- STATUS 1998/04/07 06:59:03 1.271
+++ STATUS 1998/04/07 12:36:26 1.272
@@ -299,16 +299,16 @@
* What prefixes to use for the renaming:
- Apache provided general functions (e.g., ap_cpystrn)
- ap_xxx: +1: Ken, Brian, Ralf, Martin, Paul, Roy, Jim, Randy
+ ap_xxx: +1: Ken, Brian, Ralf, Martin, Paul, Roy, Randy
- Public API functions (e.g., palloc)
ap_xxx: +1: Ralf, Roy, Dean, Randy, Martin, Brian
- apapi_xxx: +1: Ken, Paul, Jim
+ apapi_xxx: +1: Ken, Paul
- Private functions which we can't make static (because of
cross-object usage) but should be (e.g., new_connection)
ap_xxx: +1: Roy, Dean, Randy, Martin, Brian
- apx_xxx: +1: Ralf, Jim
+ apx_xxx: +1: Ralf
appri_xxx: +1: Paul, Ken
- Public API module structure variables (e.g.,
@@ -316,7 +316,7 @@
mod_so, etc and have to be exported:
..._module:+1: Roy [status quo], Dean
ap_xxx: +1:
- apm_xxx: +1: Ralf, Jim
+ apm_xxx: +1: Ralf
Notes:
- Ralf: My opinion for my decisions are the following ones:
@@ -386,16 +386,6 @@
- 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
- isn't. In my mind, we should use prefixed not JUST
- to prevent namespace collisions, but also to
- "define" the type function. The very fact that we
- _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
