dgaudet 98/04/06 23:56:53
Modified: . STATUS
Log:
oh yeah whatever
Revision Changes Path
1.270 +20 -0 apache-1.3/STATUS
Index: STATUS
===================================================================
RCS file: /export/home/cvs/apache-1.3/STATUS,v
retrieving revision 1.269
retrieving revision 1.270
diff -u -r1.269 -r1.270
--- STATUS 1998/04/07 06:41:29 1.269
+++ STATUS 1998/04/07 06:56:52 1.270
@@ -317,6 +317,7 @@
..._module:+1: Roy [status quo]
ap_xxx: +1:
apm_xxx: +1: Ralf, Jim
+ ap_mod_xxx:+1: Dean
Notes:
- Ralf: My opinion for my decisions are the following ones:
@@ -363,6 +364,25 @@
apapi_vformatter is making me puke. So many extra
characters, so much wasted screen width, and
keystrokes.
+
+ Furthermore, nobody has explained just what happens when
+ functions which are "part of the API", such as palloc
+ suddenly get moved to libap and are no longer "part of
+ the API". Calling it apapi_palloc is foolish. The name
+ "ap_palloc" has two prefixes for those not paying attention,
+ the first "ap_" protects apache's namespace. The next,
+ "p" indicates it is a pool function. Similarly we would
+ have "ap_table_get". There's no need to waste space with
+ "apapi_table_get", the "api" part is just redundant.
+
+ If folks can't figure out what is in the api and what
+ isn't THEN IT'S IS A DOCUMENTATION PROBLEM. It's not
+ a code problem. They have to look in header files or
+ other docs anyhow to learn how to use a function, so why
+ should they repeatedly type apapi ?
+
+ ap_ is a name space protection mechanism, it is not a
+ documentation mechanism.
- Randy: I agree with Dean 100%. The work created to
keep this straight far outweighs any gain this
