2.0 naming

[Doug MacEachern <do...@covalent.net>]

i'm just starting to play with 2.0, i think all (well, most) macros should
have an AP_ prefix, e.g.
HOOK_MIDDLE       -> AP_HOOK_MIDDLE
MODULE_VAR_EXPORT -> AP_MODULE_VAR_EXPORT

etc.

it might also be a good time to remove the backward-compat HTTP_ aliases,
e.g.

httpd.h:454:#define DOCUMENT_FOLLOWS    HTTP_OK
httpd.h:455:#define PARTIAL_CONTENT     HTTP_PARTIAL_CONTENT

i don't think the HTTP_* macros need an AP_ prefix, but wouldn't complain
if they did.

and some names that always bugged me carried over from 1.x:

ap_hook_check_user_id
 to
ap_hook_authentication_checker

ap_hook_auth_checker
 to
ap_hook_authorization_checker

it might seem painful, but if we want squeeky clean namespace, better now
than later.  i can make time to implement any of these changes too.

Re: 2.0 naming

[Greg Stein <gs...@lyra.org>]

+1 on all points!

Since the hook stuff is new to 2.0, it doesn't even need to be
grandfathered. The HTTP_* has been around long enough for people to switch
over. If they haven't yet, then screw 'em :-)

Cheers,
-g

On Fri, 31 Mar 2000, Doug MacEachern wrote:

> i'm just starting to play with 2.0, i think all (well, most) macros should
> have an AP_ prefix, e.g.
> HOOK_MIDDLE       -> AP_HOOK_MIDDLE
> MODULE_VAR_EXPORT -> AP_MODULE_VAR_EXPORT
> 
> etc.
> 
> it might also be a good time to remove the backward-compat HTTP_ aliases,
> e.g.
> 
> httpd.h:454:#define DOCUMENT_FOLLOWS    HTTP_OK
> httpd.h:455:#define PARTIAL_CONTENT     HTTP_PARTIAL_CONTENT
> 
> i don't think the HTTP_* macros need an AP_ prefix, but wouldn't complain
> if they did.
> 
> and some names that always bugged me carried over from 1.x:
> 
> ap_hook_check_user_id
>  to
> ap_hook_authentication_checker
> 
> ap_hook_auth_checker
>  to
> ap_hook_authorization_checker
> 
> it might seem painful, but if we want squeeky clean namespace, better now
> than later.  i can make time to implement any of these changes too.
> 

-- 
Greg Stein, http://www.lyra.org/

Re: 2.0 naming

[Chuck Murcko <ch...@topsail.org>]

Greg Stein wrote:
> 
> On Wed, 26 Apr 2000, Doug MacEachern wrote:
> > i just committed a change that adds the AP_ prefix to *HOOK* macros.
> > i wanted to revisit this before moving forward with more renaming.
> > below is a list of #defines that a script plucked out of *.h and i pruned
> > down a bit by hand.  anything that already existed in 1.x is prefixed with
> > 1.x (not 100% accurate).  if the 1.x names were to be prefixed with AP_,
> > then there should probably be an ap_compat.h file that #defines all the
> > old names to the new AP_ ones.
> > this is sorta painful, but i would really like to see it happen, anybody
> > have strong feelings either way?
> 
> +1 on adding AP_ prefixes at your discretion.
> 
> -0 on adding entries to ap_compat.h. IMO, we should just nuke that file
> and be done with it. This is a 2.x upgrade that requires recompilation and
> file edits. Telling people to add AP_ or ap_ prefixes to their symbols
> isn't a hardship for them.
> 
Yes, +1 here too, although I've always felt the prefix we picked was too
short to stay unique for long.

ap_compat.h should go away before a real release, IMHO. We're not
providing abackward compatibility path for modules in 2.x, so we should
not give any illusions that we are.
-- 
Chuck
Chuck Murcko
Topsail Group
chuck@topsail.org

Re: 2.0 naming

[Greg Stein <gs...@lyra.org>]

On Wed, 26 Apr 2000, Doug MacEachern wrote:
> i just committed a change that adds the AP_ prefix to *HOOK* macros.  
> i wanted to revisit this before moving forward with more renaming.
> below is a list of #defines that a script plucked out of *.h and i pruned
> down a bit by hand.  anything that already existed in 1.x is prefixed with
> 1.x (not 100% accurate).  if the 1.x names were to be prefixed with AP_,
> then there should probably be an ap_compat.h file that #defines all the
> old names to the new AP_ ones.  
> this is sorta painful, but i would really like to see it happen, anybody
> have strong feelings either way?

+1 on adding AP_ prefixes at your discretion.

-0 on adding entries to ap_compat.h. IMO, we should just nuke that file
and be done with it. This is a 2.x upgrade that requires recompilation and
file edits. Telling people to add AP_ or ap_ prefixes to their symbols
isn't a hardship for them.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

RE: 2.0 naming

["William A. Rowe, Jr." <wr...@lnd.com>]

> From: Doug MacEachern [mailto:dougm@covalent.net]
> Sent: Wednesday, April 26, 2000 3:52 PM
> 
> > The following names are problematic...
> >  
> > > 1. API_EXPORT
> > > 1. API_EXPORT_NONSTD
> > > 1. MODULE_VAR_EXPORT
> > > 1. API_VAR_EXPORT
> > > 1. CORE_EXPORT
> > > 1. CORE_EXPORT_NONSTD
> > 
> > API_* will become one of TWO different sets of names, and I was
> > going to kep API_* for the Apache core componenents.  CORE_*
> > wrappers are actually notes to the implementor, not really any
> > different from API_ wrappers.  *_VAR_EXPORT really should
> > become *_EXPORT_VAR, and MODULE_VAR_EXPORT become simply EXPORT_VAR,
> > since it is involitale (it won't change by context.)
> > 
> > All API_* declarations in the apr library headers were to become 
> > APR_*.  I don't care if these become AP_ instead, however. The
> > point is they must be split, and declarations for APR_ (or AP_)
> > updated in the apr header files.
> 
> you sorta lost me, can i leave those names for you to tackle?

Assuredly.
 
> personally, i'd like to see the AP_ prefix used in apr as 
> well, as all the
> functions are prefixed ap_ and not apr_.  but, i probably missed that
> discussion already.

Well... so are the httpd functions, but that doesn't keep us from 
requiring two or more pools of function wrappers (one per shared library
target, except in the case of MODULE_ stuff which is always simply
exported and never imported - I hope).

I will take that as a + for AP_EXPORT* to wrap apr labels, and tackle 
those alone over the weekend.  I will leave (correct, in some cases) 
API_EXPORT* for the apache kernel.  If anyone doesn't like that when 
I finish... well, then they will be able to grep the whole nonsense
to more meaningful wrapper names.

RE: 2.0 naming

[Doug MacEachern <do...@covalent.net>]

On Wed, 26 Apr 2000, William A. Rowe, Jr. wrote:
  
> The complete list you submitted looks to long to toss as one patch.

i know, i plan to do the renaming in small groups, which is why i started
with just the hook #defines.

> Many look like Standard C names, but I didn't dig into them.  To

yeah, i will dig into them to make sure before any renaming.

> make it manageable, can I suggest focusing on the APR declared
> names first, before tackling httpd?

sure.

> The following names are problematic...
>  
> > 1. API_EXPORT
> > 1. API_EXPORT_NONSTD
> > 1. MODULE_VAR_EXPORT
> > 1. API_VAR_EXPORT
> > 1. CORE_EXPORT
> > 1. CORE_EXPORT_NONSTD
> 
> API_* will become one of TWO different sets of names, and I was
> going to kep API_* for the Apache core componenents.  CORE_*
> wrappers are actually notes to the implementor, not really any
> different from API_ wrappers.  *_VAR_EXPORT really should
> become *_EXPORT_VAR, and MODULE_VAR_EXPORT become simply EXPORT_VAR,
> since it is involitale (it won't change by context.)
> 
> All API_* declarations in the apr library headers were to become 
> APR_*.  I don't care if these become AP_ instead, however. The
> point is they must be split, and declarations for APR_ (or AP_)
> updated in the apr header files.

you sorta lost me, can i leave those names for you to tackle?

personally, i'd like to see the AP_ prefix used in apr as well, as all the
functions are prefixed ap_ and not apr_.  but, i probably missed that
discussion already.

RE: 2.0 naming

["William A. Rowe, Jr." <wr...@lnd.com>]

> From: Doug MacEachern [mailto:dougm@covalent.net]
> Sent: Wednesday, April 26, 2000 2:35 AM
 
The complete list you submitted looks to long to toss as one patch.
Many look like Standard C names, but I didn't dig into them.  To
make it manageable, can I suggest focusing on the APR declared
names first, before tackling httpd?

The following names are problematic...
 
> 1. API_EXPORT
> 1. API_EXPORT_NONSTD
> 1. MODULE_VAR_EXPORT
> 1. API_VAR_EXPORT
> 1. CORE_EXPORT
> 1. CORE_EXPORT_NONSTD

API_* will become one of TWO different sets of names, and I was
going to kep API_* for the Apache core componenents.  CORE_*
wrappers are actually notes to the implementor, not really any
different from API_ wrappers.  *_VAR_EXPORT really should
become *_EXPORT_VAR, and MODULE_VAR_EXPORT become simply EXPORT_VAR,
since it is involitale (it won't change by context.)

All API_* declarations in the apr library headers were to become 
APR_*.  I don't care if these become AP_ instead, however. The
point is they must be split, and declarations for APR_ (or AP_)
updated in the apr header files.

Re: 2.0 naming

[Doug MacEachern <do...@covalent.net>]

i just committed a change that adds the AP_ prefix to *HOOK* macros.  
i wanted to revisit this before moving forward with more renaming.
below is a list of #defines that a script plucked out of *.h and i pruned
down a bit by hand.  anything that already existed in 1.x is prefixed with
1.x (not 100% accurate).  if the 1.x names were to be prefixed with AP_,
then there should probably be an ap_compat.h file that #defines all the
old names to the new AP_ ones.  
this is sorta painful, but i would really like to see it happen, anybody
have strong feelings either way?

1. API_EXPORT
1. API_EXPORT_NONSTD
1. MODULE_VAR_EXPORT
1. API_VAR_EXPORT
1. CORE_EXPORT
1. CORE_EXPORT_NONSTD
DECLARE_HOOK
HOOK_STRUCT
HOOK_LINK
IMPLEMENT_HOOK_BASE
IMPLEMENT_HOOK_VOID
IMPLEMENT_HOOK_RUN_ALL
IMPLEMENT_HOOK_RUN_FIRST
HOOK_REALLY_FIRST
HOOK_FIRST
HOOK_MIDDLE
HOOK_LAST
HOOK_REALLY_LAST
iol_close
iol_write
iol_writev
iol_read
iol_setopt
iol_getopt
iol_sendfile
iol_shutdown
LISTEN_COMMANDS
1. MODULE_MAGIC_COOKIE
1. MODULE_MAGIC_NUMBER_MAJOR
1. MODULE_MAGIC_NUMBER_MINOR
1. MODULE_MAGIC_NUMBER
1. MODULE_MAGIC_AT_LEAST
OC_REASON_DEATH
OC_REASON_UNWRITABLE
OC_REASON_RESTART
OC_REASON_UNREGISTER
OC_REASON_LOST
SHA_DIGESTSIZE
1. B_RD
1. B_WR
1. B_RDWR
1. B_EOF
1. B_EOUT
1. B_RDERR
1. B_WRERR
1. B_ERROR
1. B_CHUNK
1. B_NONBLOCK
1. BO_BYTECT
1. BO_TIMEOUT
1. BO_ERROR
1. OR_NONE
1. OR_LIMIT
1. OR_OPTIONS
1. OR_FILEINFO
1. OR_AUTHCFG
1. OR_INDEXES
1. OR_UNSET
1. OR_ALL
1. ACCESS_CONF
1. RSRC_CONF
1. DECLINE_CMD
1. STANDARD_MODULE_STUFF
STANDARD20_MODULE_STUFF
MPM20_MODULE_STUFF
1. NOT_IN_VIRTUALHOST
1. NOT_IN_LIMIT
1. NOT_IN_DIRECTORY
1. NOT_IN_LOCATION
1. NOT_IN_FILES
1. NOT_IN_DIR_LOC_FILE
1. GLOBAL_ONLY
1. OPT_NONE
1. OPT_INDEXES
1. OPT_INCLUDES
1. OPT_SYM_LINKS
1. OPT_EXECCGI
1. OPT_UNSET
1. OPT_INCNOEXEC
1. OPT_SYM_OWNER
1. OPT_MULTI
1. OPT_ALL
1. REMOTE_HOST
1. REMOTE_NAME
1. REMOTE_NOLOOKUP
1. REMOTE_DOUBLE_REV
1. SATISFY_ALL
1. SATISFY_ANY
1. SATISFY_NOSPEC
1. HOSTNAME_LOOKUP_OFF
1. HOSTNAME_LOOKUP_ON
1. HOSTNAME_LOOKUP_DOUBLE
1. HOSTNAME_LOOKUP_UNSET
1. ADD_DEFAULT_CHARSET_OFF
1. ADD_DEFAULT_CHARSET_ON
1. ADD_DEFAULT_CHARSET_UNSET
1. LOG_PRIMASK
#APLOG_EMERG
#APLOG_ALERT
#APLOG_CRIT
#APLOG_ERR
#APLOG_WARNING
#APLOG_NOTICE
#APLOG_INFO
#APLOG_DEBUG
#APLOG_LEVELMASK
#APLOG_NOERRNO
#APLOG_STARTUP
1. DEFAULT_LOGLEVEL
#APLOG_MARK
1. HTTPD_ROOT
1. DOCUMENT_LOCATION
1. DYNAMIC_MODULE_LIMIT
1. DEFAULT_ADMIN
1. TARGET
1. DEFAULT_USER
1. DEFAULT_GROUP
1. DEFAULT_XFERLOG
1. DEFAULT_ERRORLOG
1. DEFAULT_ACCESS_FNAME
1. SERVER_CONFIG_FILE
1. DEFAULT_RFC1413
1. DEFAULT_PATH
1. SUEXEC_BIN
1. DEFAULT_TIMEOUT
1. DEFAULT_KEEPALIVE_TIMEOUT
1. DEFAULT_KEEPALIVE
1. DEFAULT_LISTENBACKLOG
1. DEFAULT_LIMIT_REQUEST_LINE
1. DEFAULT_LIMIT_REQUEST_FIELDSIZE
1. DEFAULT_LIMIT_REQUEST_FIELDS
1. DEFAULT_ADD_DEFAULT_CHARSET_NAME
1. DEFAULT_INDEXING
1. DEFAULT_CONTENT_TYPE
1. DOCTYPE_HTML_2_0
1. DOCTYPE_HTML_3_2
1. DOCTYPE_HTML_4_0S
1. DOCTYPE_HTML_4_0T
1. DOCTYPE_HTML_4_0F
1. DEFAULT_HTTP_PORT
1. DEFAULT_HTTPS_PORT
1. MAX_STRING_LEN
1. HUGE_STRING_LEN
1. IOBUFSIZE
#APEXIT_OK
#APEXIT_INIT
#APEXIT_CHILDINIT
#APEXIT_CHILDFATAL
1. DECLINED
1. DONE
1. OK
1. RESPONSE_CODES
1. M_GET
1. M_PUT
1. M_POST
1. M_DELETE
1. M_CONNECT
1. M_OPTIONS
1. M_TRACE
1. M_PATCH
1. M_PROPFIND
1. M_PROPPATCH
1. M_MKCOL
1. M_COPY
1. M_MOVE
1. M_LOCK
1. M_UNLOCK
1. M_INVALID
1. METHODS
1. CGI_MAGIC_TYPE
1. INCLUDES_MAGIC_TYPE
1. INCLUDES_MAGIC_TYPE3
1. DIR_MAGIC_TYPE
1. ASCIITEXT_MAGIC_TYPE_PREFIX
1. LF
1. CR
1. CRLF
1. REQUEST_NO_BODY
1. REQUEST_CHUNKED_ERROR
1. REQUEST_CHUNKED_DECHUNK
1. REQUEST_CHUNKED_PASS
1. DEFAULT_VHOST_ADDR
SIGSTOP_DETACH
SIGSTOP_MAKE_CHILD
SIGSTOP_SPAWN_CHILD
SIGSTOP_PIPED_LOG_SPAWN
SIGSTOP_CGI_CHILD
RAISE_SIGSTOP
1. BAD_DATE
1. DEFAULT_FTP_DATA_PORT
1. DEFAULT_FTP_PORT
1. DEFAULT_GOPHER_PORT
1. DEFAULT_NNTP_PORT
1. DEFAULT_WAIS_PORT
1. DEFAULT_SNEWS_PORT
1. DEFAULT_PROSPERO_PORT
1. UNP_OMITSITEPART
1. UNP_OMITUSER
1. UNP_OMITPASSWORD
1. UNP_OMITUSERINFO
1. UNP_REVEALPASSWORD
1. UNP_OMITPATHINFO
1. UNP_OMITQUERY
#TRUE
#FALSE
MAXIMUM_WAIT_OBJECTS
1. XtOffset
1. XtOffsetOf
1. MD5_DIGESTSIZE
MAX_SECS_TO_LINGER
APRMAXHOSTLEN
BLOCK_MINFREE
BLOCK_MINALLOC
API_THREAD_FUNC
1. API_VAR_IMPORT
1. SHELL_PATH
DEFAULT_START_THREAD
DEFAULT_MAX_SPARE_THREAD
DEFAULT_MIN_SPARE_THREAD
HARD_THREAD_LIMIT
DEFAULT_NUM_DAEMON
1. HARD_SERVER_LIMIT
1. DEFAULT_LOCKFILE
1. DEFAULT_PIDLOG
1. SCOREBOARD_MAINTENANCE_INTERVAL
1. DEFAULT_MAX_REQUESTS_PER_CHILD
1. KEY_LENGTH
1. VALUE_LENGTH
1. STATUSES_PER_CONNECTION
1. SCOREBOARD_SIZE
1. DEFAULT_START_DAEMON
1. DEFAULT_MAX_FREE_DAEMON
1. DEFAULT_MIN_FREE_DAEMON
DEFAULT_THREADS_PER_CHILD
1. DEFAULT_SCOREBOARD
1. OPTIMIZE_TIMEOUTS
1. SERVER_DEAD
1. SERVER_STARTING
1. SERVER_READY
1. SERVER_BUSY_READ
1. SERVER_BUSY_WRITE
1. SERVER_BUSY_KEEPALIVE
1. SERVER_BUSY_LOG
1. SERVER_BUSY_DNS
1. SERVER_GRACEFUL
1. SERVER_ACCEPTING
1. SERVER_QUEUEING
1. SERVER_NUM_STATUS
1. NEW_SCOREBOARD_SIZE
1. SCOREBOARD_NAME
1. SCOREBOARD_FRAMES
START_PREQUEST
STOP_PREQUEST
#TESTING
HDR_APP
HDR_REP
HASH_LEN
CACHEFILE_LEN
SEC_ONE_DAY
SEC_ONE_HR
DEFAULT_CACHE_SPACE
DEFAULT_CACHE_MAXEXPIRE
DEFAULT_CACHE_EXPIRE
DEFAULT_CACHE_LMFACTOR
DEFAULT_CACHE_COMPLETION
1. HTTPD_USER
1. UID_MIN
1. GID_MIN
1. USERDIR_SUFFIX
1. LOG_EXEC
1. DOC_ROOT
1. SAFE_PATH