You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 1998/03/30 01:40:19 UTC
Re: cvs commit: apache-1.3/src/modules/standard mod_expires.c
mod_include.c mod_log_config.c mod_rewrite.c mod_usertrack.c
dgaudet@hyperreal.org wrote:
>
> dgaudet 98/03/28 03:58:37
>
> Log:
> Finally dealt with the vformatter() thing that's been sitting in STATUS
> since october.
>
> - apapi_vformatter() is generic printf-style routine with arbitrary
> output
Blimey! I'm offline for three days while I install a new computer
desk, and the world tilts!
I haven't looked at this yet, but is it really "apapi_" - that is,
it contains dependencies on the httpd core, like pools or something?
Remember, ap_snprintf() was *not* dependent upon the core for
anything, and thus was broken out into libap so it could be used
by non-httpd things.
If the new vformatter() doobie is like this, the name should be "ap_"
rather than "apapi_". If it *does* contain dependencies, can it
be further reduced to those pieces that do and those that don't,
so the parts that don't can go into libap for general use (i.e., inclusion
in the nascent "Apache Reusable Software Library" effort)?
Or am I being a total ass for speaking up without checking first?
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://WWW.Dummies.Com/
Re: prefixes
Posted by Paul Sutton <pa...@c2.net>.
On Sun, 29 Mar 1998, Brian Behlendorf wrote:
> Looks like consensus is to use apapi_ for API functions.
>
> >os_ some other random core functions
>
> Wasn't this for routines that turn OS-nonspecific semantics into
> OS-specific calls? My vote would be to make this ap_.
The distinction between os_ and ap_ is that os_ does not require the
overhead of things like pools (which are going to be part of the ap_
libraries). For example, the fairly simple support programs can link
against os_ to get os-independent functionality consistent with Apache,
without needing any of the libap stuff. In general, most things in with
os_ prefixes will be short macros or inline functions, or (on many
systems) simply nops.
To my mind this is a fairly clear distinction, and having different
libraries and prefixes makes this clear to people writing Apache add ons.
But perhaps we don't need it.
Paul
Re: prefixes
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 29 Mar 1998, Brian Behlendorf wrote:
> At 05:53 PM 3/29/98 -0800, Dean Gaudet wrote:
> >apapi_vformatter contains no dependencies on the core.
>
> Moving it to ap_vformatter was the right thing to do, then.
>
> >I don't see the point in having 5 million different prefixes. I don't see
> >the point in having 5 different prefixes. I would rather have one prefix
> >and use it everywhere. At the moment we've got the following:
> >
> >AP_ stuff that doesn't have any other prefix
> >ap_ some stuff that fits your description of generic library tools
> > with no dependency on core (i.e. ap_snprintf), and some stuff
> > that does depend on core (i.e. ap_escape_quotes)
>
> That should be cleaned up. What other funcs besides ap_escape_quotes?
> Looks like that's the only func in src/ap that takes a pool pointer as a
> parameter, and could probably be modified to handle static buffers...
But pools are a generic thing that should be part of a library. What do
you do then when someone gets around to cleaning it up and sticking it
into libap? Do you go around renaming apapi_escape_quotes to
ap_escape_quotes?
For example suppose palloc was rewritten like this:
void *palloc(pool *p)
{
ap_block_alarms();
ap_mutex_acquire(&alloc_mutex);
.. do the allocation thing ..
if (out of memory) {
ap_mutex_release(&alloc_mutex);
ap_unblock_alarms();
ap_fatal_exception("out of memory!");
}
ap_mutex_release(&alloc_mutex);
ap_unblock_alarms();
return result;
}
And suppose there was a file fatal.c in libap:
/* default fatal exception handler, just bail */
void __attribute__((noreturn)) ap_fatal_exception(const char *msg)
{
fputs(msg, stderr);
exit(1);
}
and a file alarms.c in libap:
/* default alarms handler, do nothing */
void ap_block_alarms(void) {}
void ap_unblock_alarms(void) {}
Then if the application has a need (i.e. httpd) it can override these
defaults and do whatever it wants to... for example the exception handler
could actually use longjmp to implement a set of nested exceptions just
like C++ provides (except we can't use for portability reasons ;).
I'd love to have pools available for use outside httpd, it would make the
library more useful for writing generic servers. And there's not much
standing in the way of that.
Once pools are in libap you can start moving a LOT of other useful
functions into libap. At some point you'll discover that BUFF itself
can be in libap. It's generic too modulo the alarm handling again.
At some point you have to draw a line between what is httpd and what
is its support library. I'd say that line starts somewhere around the
request_rec and server_rec structures. Stuff which manipulates those
shouldn't be in the library. But pools, BUFFs, uri parsing, there's
lots of things that should be in the library.
> In so far as we want to have a 1) library of reusable code and 2) real API,
> having distinct prefixes is helpful.
I'm not saying we shouldn't have distinct prefixes. I'm noting that
we need prefixes IN ADDITION to whatever prefix we choose to protect
our namespace. I'm not against a plethora of prefixes for subsystems
within our code, but I'm against a plethora of prefixes which are there
to protect our namespace.
I see ap_, apapi_, and appri_ as prefixes which just protect the
namespace. We need only one.
Dean
prefixes
Posted by Brian Behlendorf <br...@hyperreal.org>.
At 05:53 PM 3/29/98 -0800, Dean Gaudet wrote:
>apapi_vformatter contains no dependencies on the core.
Moving it to ap_vformatter was the right thing to do, then.
>I don't see the point in having 5 million different prefixes. I don't see
>the point in having 5 different prefixes. I would rather have one prefix
>and use it everywhere. At the moment we've got the following:
>
>AP_ stuff that doesn't have any other prefix
>ap_ some stuff that fits your description of generic library tools
> with no dependency on core (i.e. ap_snprintf), and some stuff
> that does depend on core (i.e. ap_escape_quotes)
That should be cleaned up. What other funcs besides ap_escape_quotes?
Looks like that's the only func in src/ap that takes a pool pointer as a
parameter, and could probably be modified to handle static buffers...
>apapi_ two random new core functions
>aplog_ another random core function
Looks like consensus is to use apapi_ for API functions.
>os_ some other random core functions
Wasn't this for routines that turn OS-nonspecific semantics into
OS-specific calls? My vote would be to make this ap_.
>... and at least one more that's proposed but unused, appri_ or whatever
>you want to call it.
I think the AP_ system makes this unnecessary anymore, true?
>This is ridiculous. Apache is 72k lines of code. If we can't keep our
>own symbols from colliding with each other then we've got serious problems.
>We need only one prefix.
In so far as we want to have a 1) library of reusable code and 2) real API,
having distinct prefixes is helpful.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Optimism is a strategy for making brian@apache.org
a better future." - Noam Chomsky brian@hyperreal.org
Re: cvs commit: apache-1.3/src/modules/standard mod_expires.c mod_include.c mod_log_config.c mod_rewrite.c mod_usertrack.c
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 29 Mar 1998, Rodent of Unusual Size wrote:
> Dean Gaudet wrote:
> >
> > I don't see the point in having 5 million different prefixes. I don't see
> > the point in having 5 different prefixes. I would rather have one prefix
> > and use it everywhere. At the moment we've got the following:
> >
> > AP_ stuff that doesn't have any other prefix
>
> Ralf just stuck that in the hide.h file because the prefix nomenclature
> was still undecided.
It is a defacto part of our API now, and something that I have to type
every time I'm debugging.
> > ... and at least one more that's proposed but unused, appri_ or whatever
> > you want to call it.
>
> That's what UpdateHide should be changed to use instead of AP_.
Uh, no. 99% of the AP_ functions are public parts of the API.
> My experience with this sort of stuff over the last couple of decades
> has shown clear nomenclature to be highly beneficial; you can tell at
> a glance whether something's available, under what circumstances,
> and where you might expect to find soi-disant documentation.
On million line source bases I'll agree with you. I refuse to agree with
you on something as small as Apache. How hard is this?
vi `find include -name \*.h -print | xargs grep -l funcname`
? Put it into a script if you don't like typing it. Here's one that
folks may find useful, I call it rgrep:
#!/bin/sh
find . '(' -name '*.[cChHylsS]' -o -name '*.cpp' -o -name '*.[cC][cC]' ')' -print0 | xargs -0r grep ${1+"$@"}
But maybe I'm just spoiled with a development machine with enough RAM
to hold the entire source tree in cache and make things like the above
run real fast. I'll agree with that. But Apache is small, it doesn't
take much RAM to hold it. I use the above on much larger trees,
on the order of 200Mb of source code.
Remember that on top of the "apapi" part of the name you're going to
need other special tokens ... which means the names are going to be
really really long. For example, all the rfoo() routines which dump
output to the request client... they've all got that "r" in there.
There's all the "p" pool routines, and all the "table_" table routines,
and all the "array_" array routines... apapi_array_copy ? Wow cool,
I can almost fit that on one line with its first parameter, and if I'm
lucky I'll only have one more line break.
I can't stand the amount of typing and reading that you're saying we'll
need to perform. It's ludicrous.
Dean
Re: cvs commit: apache-1.3/src/modules/standard mod_expires.c
mod_include.c mod_log_config.c mod_rewrite.c mod_usertrack.c
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> I don't see the point in having 5 million different prefixes. I don't see
> the point in having 5 different prefixes. I would rather have one prefix
> and use it everywhere. At the moment we've got the following:
>
> AP_ stuff that doesn't have any other prefix
Ralf just stuck that in the hide.h file because the prefix nomenclature
was still undecided.
> ap_ some stuff that fits your description of generic library tools
> with no dependency on core (i.e. ap_snprintf), and some stuff
> that does depend on core (i.e. ap_escape_quotes)
Whoops, ap_escape_quotes() *does* have a dependency. Bugger. It needs
to be fixed, then. Thanx for pointing that out. The ap_ prefix is
supposed to be for Apache routines/interfaces/whatever that don't have
any dependencies outside of src/ap, so the libap.a can be included if
someone's linking some external programme. ap_escape_quotes() breaks
that.
> apapi_ two random new core functions
No, not random, just new. Since the API public interface prefix had been
essentially approved to be "apapi_" (see STATUS) they just happened to
be the first.
> aplog_ another random core function
I've mentioned this as needing fixing before.
> os_ some other random core functions
Not random at all - different implementations that are OS-specific.
Considering the amount of #ifdefing around, I could see a case
being made for this being re-evaluated.
> ... and at least one more that's proposed but unused, appri_ or whatever
> you want to call it.
That's what UpdateHide should be changed to use instead of AP_.
> This is ridiculous. Apache is 72k lines of code. If we can't keep our
> own symbols from colliding with each other then we've got serious problems.
> We need only one prefix.
{Sigh} Wrong-o. We have a mix of things that are part of the API (or
would be if the bloody thing were published and documented - I'm
working on it..), things that are for core-use only, and things which
are 'reusable.' Three prefixes: apapi_, appri_, and ap_.
My experience with this sort of stuff over the last couple of decades
has shown clear nomenclature to be highly beneficial; you can tell at
a glance whether something's available, under what circumstances,
and where you might expect to find soi-disant documentation.
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://WWW.Dummies.Com/
Re: cvs commit: apache-1.3/src/modules/standard mod_expires.c mod_include.c mod_log_config.c mod_rewrite.c mod_usertrack.c
Posted by Dean Gaudet <dg...@arctic.org>.
apapi_vformatter contains no dependencies on the core.
I don't see the point in having 5 million different prefixes. I don't see
the point in having 5 different prefixes. I would rather have one prefix
and use it everywhere. At the moment we've got the following:
AP_ stuff that doesn't have any other prefix
ap_ some stuff that fits your description of generic library tools
with no dependency on core (i.e. ap_snprintf), and some stuff
that does depend on core (i.e. ap_escape_quotes)
apapi_ two random new core functions
aplog_ another random core function
os_ some other random core functions
... and at least one more that's proposed but unused, appri_ or whatever
you want to call it.
This is ridiculous. Apache is 72k lines of code. If we can't keep our
own symbols from colliding with each other then we've got serious problems.
We need only one prefix.
Dean
On Sun, 29 Mar 1998, Rodent of Unusual Size wrote:
> dgaudet@hyperreal.org wrote:
> >
> > dgaudet 98/03/28 03:58:37
> >
> > Log:
> > Finally dealt with the vformatter() thing that's been sitting in STATUS
> > since october.
> >
> > - apapi_vformatter() is generic printf-style routine with arbitrary
> > output
>
> Blimey! I'm offline for three days while I install a new computer
> desk, and the world tilts!
>
> I haven't looked at this yet, but is it really "apapi_" - that is,
> it contains dependencies on the httpd core, like pools or something?
> Remember, ap_snprintf() was *not* dependent upon the core for
> anything, and thus was broken out into libap so it could be used
> by non-httpd things.
>
> If the new vformatter() doobie is like this, the name should be "ap_"
> rather than "apapi_". If it *does* contain dependencies, can it
> be further reduced to those pieces that do and those that don't,
> so the parts that don't can go into libap for general use (i.e., inclusion
> in the nascent "Apache Reusable Software Library" effort)?
>
> Or am I being a total ass for speaking up without checking first?
>
> #ken P-)}
>
> Ken Coar <http://Web.Golux.Com/coar/>
> Apache Group member <http://www.apache.org/>
> "Apache Server for Dummies" <http://WWW.Dummies.Com/
>