httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: cvs commit: apache-1.3 STATUS
Date Mon, 30 Mar 1998 14:29:53 GMT
Excellent summary...

Paul Sutton wrote:
> On Sun, 29 Mar 1998, Dean Gaudet wrote:
> > Sheesh.  Have I mentioned anything about what comes AFTER the prefix?  NO! 
> > I haven't.  If you look at my track record you'll see that I don't create
> > obscure function names.  pool_is_ancestor, core_reorder_directories,
> > register_other_child.  I may use short local variables such as "p", or
> > "i", or "u".  But that is entirely acceptable given that they have only a
> > small scope and the short names save thinking time in addition to typing
> > time. 
> I'm edging in favour of Dean's proposal at the moment. A consistent ap_
> prefix It looks much neater and more elgant.
> But lets step back a moment, and look at what we are trying to achieve.
> We want to give people access to the API at various levels (or that could
> be expressed as, give people access to various APIs):
>   - basic functionality required on all platforms but where OS support
>     varies. Does not require libap. All functions have prefix os_
>   - generic functionality useful for Apache and possibly other web or
>     general code. This is libap, functions have prefix ap_. 
>   - specific functionaliy required only by modules liked to Apache.
>     Currently has no prefix hiding, but proposed is apapi_.
>   - internal functions, not accessible to modules. Currently has no
>     prefix hiding, but proposed is appri_.
> In a table, this comes out as
>                                  Proposed
>    Provider      Directory       Prefix      Used by?
>    ------------  --------------  ----------  --------------------------
>    libos         os/*            os_         Any portable application
>    libap         ap              ap_         Any application, but
>                                              targetted to web services
>    Apache        main            apapi_      Modules
>    Apache        main            appri_      Apache only
> At least, this is my assumption. The STATUS file lists palloc() as an
> example of something to get an apapi_ prefix, but I assumed that was
> because it was not yet in libap. Once it goes in there it should have an
> ap_ prefix.
> So at some point we will take all the functions current in the Apache
> core, and for each one identify it as one suitable for libap (if it does
> not require Apache), apapi_ (if it will only work in Apache) and appri (if
> it is not part of any provided API). Then the support programs, and
> others, can make use of libap (and libos if necessary), while modules can
> use ap_, apapi_ and os_ functions (which together make up the "Apache
> API"). 
> So, are we talking about what to put into the apapi_ and appri_ prefix
> boxes above, or are there more fundamental questions, like: do we need a
> distinction between ap_ and apapi_ provided functions?
> Paul

   Jim Jagielski   |||   |||
            "That's no ordinary rabbit... that's the most foul,
            cruel and bad-tempered rodent you ever laid eyes on"

View raw message