httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: SDBM 2.0 'namespace protection'
Date Thu, 30 Nov 2000 18:37:16 GMT

> > This could be done with a simple script, and we don't update those
> > packages all that often.  I don't like the argument that this is too
> > difficult if it is the correct solution, and if it is the correct solution
> > for SDBM, then it is the correct solution for PCRE and Expat.
> No. We would be changed the APIs of those packages. People would no longer
> be coding against PCRE or Expat, but some Apache API.
> SDBM *is* an Apache API. There is no "canonical" package for it. We have
> defined it as using the "sdbm_" prefix.

No, PCRE and Expat are external programs, but we don't distribute those,
we distribute Apache, which happens to use those.  If we don't want to
modify the APIs, then we can't compile these packages into Apache, we need
to use shared libraries.  We are NOT distributing the "canonical" packages
for Expat or PCRE, we are using them, so changing the APIs, or only
exporting API's that are wrappers around the native wrappers is okay for
us to do.

> > > It is located in lib/sdbm/ because it is a nicely modularized little
> > > library. The same goes for lib/aputil/ (assuming it grows like we've
> > > discussed so many times in the past).
> > > 
> > > lib/ does not mean "external package"; it means "a chunk of modularized code
> > > that we can pick up into our build/link". That is a "lib" to me. If we want
> > > to formalize that we're pulling in external packages, then we should have a
> > > subdir named "xpackages/" or something. That isn't on Roy's list, but if
> > > people want that subdir, then we can easily have it added.
> > 
> > A chunk of modularized code also means that it can be removed from Apache
> > and still work and make sense.  Otherwise, I don't consider it modular.
> So standard/mod_foo is not modular in your mind? modules/mpm/prefork/?
> src/ap/? Each of those files/dirs is an independent code entity. Subdirs in
> lib/ are just the same.

No they aren't the same.  standard/mod_foo is not a module, it is an
"Apache module".  The very type of module ties it to Apache and says that
it won't work outside of Apache.  src/lib is not the same thing, this
should be and has been code that can be used completely independantly of

> Ryan: lib/ subdirs do not need to be removable. They are simply isolated
> chunks of code that do not necessarily tie into Apache, or have a very light
> coupling (e.g. to APR).

Tying into APR is not the same as tying into Apache, so that isn't an

> Where else would you put SDBM, expat-lite, and aputil if not lib/? Consider
> that none of those need to be used outside of Apache. Where do they go?

SDBM, expat-lite, and APR are all useful outside of Apache proper.  The
proof of this, is that they all have their own build systems, and they are
all used in other programs.  Aputil is not useful outside of Apache.  It
relies on Apache to build, and as near as I can tell, this code is very
Apache dependant.  If this was going to be a wrapper around every
different database implementation, then I could see using it, but for that
I would steal code from PHP, because they have already solved this problem
cleanly.  I do not understand the purpose of aputil, especially not as it
currently stands.

> > > Why are pools wrong? You said the same about apu_dbm's internal type. What
> > > is wrong with using pools?! I really don't understand... :-(
> > 
> > Pools just aren't the correct solution.  Why do you want pools?  You say
> > it's to make sure we clean everything up, but that can be done in the
> > sdbm_close function, which can be called from a cleanup that is registered
> > in a wrapper function.  Taking a look at where we are using pools in sdbm,
> > it is just for sdbm_prep, which is only called by sdbm_open.  There is
> > nothing to cleanup (no cleanups are registered), we only ever allocate a
> > single structure out of this pool.  Why aren't we using malloc for
> > this?  This memory is essentially never freed as the code stands right
> > now.  If we weren't using pools, then the sdbm close function could free
> > the memory.
> Great. Now you make sense. I wish you would explain yourself, rather than
> make sweeping announcements like "we shouldn't use pools here!". Doing that
> is just plain antagonistic. Especially when the code has been like that for
> five months.

It really doesn't matter how long the code has been like that, and I have
tried to explain this before.  I may not have done as good a job as I did
yesterday, but explaining what I think has never been my strong point.

So, can I remove the pools from SDBM then?


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message