Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Thu, 30 Nov 2000 09:49:01 -0800
From: Greg Stein <gstein@lyra.org>
To: new-httpd@apache.org
Subject: Re: SDBM 2.0 'namespace protection'
Message-ID: <20001130094901.G25840@lyra.org>
Mail-Followup-To: new-httpd@apache.org
References: <20001129130646.Q25840@lyra.org>
 <Pine.LNX.4.21.0011291458320.27161-100000@koj.rkbloom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.LNX.4.21.0011291458320.27161-100000@koj.rkbloom.net>;
 from rbb@covalent.net on Wed, Nov 29, 2000 at 03:16:57PM -0800

On Wed, Nov 29, 2000 at 03:16:57PM -0800, rbb@covalent.net wrote:
> > > Ummmm.....  Expat and PCRE haven't been namespace protected.  I personally
> > > believe they should, but they aren't now.
> > 
> > Those are external packages. It would be a bitch to keep them maintained if
> > we heavily patched them. SDBM is an Apache-internal package, so we're free
> > to make it as Apache-specific as we'd like.
> 
> 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.

> > 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.

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).

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?

> > > The reason for losing those mods, is that pools are the wrong solution, as
> > > is, I believe APR.  APR would be the correct solution if it wasn't tied to
> > > pools, but it is.
> > 
> > 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.

Cheers,
-g

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