You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/07/13 18:17:41 UTC
src/lib/sdbm
>From STATUS:
* add SDBM into src/lib/sdbm/ as a default/fallback DBM
implementation.
SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM
support.
Status: Greg +1 (volunteers)
Are we actually including SDBM with Apache now? Why don't we just provide
an interface to it? It seems that with Apache 2.0, we are including all
of the libraries that Apache could ever possibly use, whether the modules
use them or not. With Apache 1.3, the general rule seemed to be that if
you wanted to take advantage of a given modules, you needed to go out and
get the libraries it required first. Why did we get away from that
mind-set?
Are we at least not building SDBM if none of the modules being built need
it?
How does this interact with the other modules listed above? When we added
expat, we broke mod_perl at least, and possibly other modules that were
using expat. By adding SDBM, are we breaking any of the modules that have
their own SDBM interface?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: src/lib/sdbm
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jul 13, 2000 at 09:17:41AM -0700, rbb@covalent.net wrote:
>
> >From STATUS:
>
> * add SDBM into src/lib/sdbm/ as a default/fallback DBM
> implementation.
> SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM
> support.
> Status: Greg +1 (volunteers)
>
> Are we actually including SDBM with Apache now? Why don't we just provide
> an interface to it?
Yes. Not as helpful. The problem is that SDBM is not readily available, so
saying "get SDBM" will be tough for users.
We cannot require GDBM because of licensing. We could depend on BSD DB, but
as I posted here a couple months back, it is a little bit shaky in certain
configs, and DB 2.0's licensing isn't as nice. More on this below.
> It seems that with Apache 2.0, we are including all
> of the libraries that Apache could ever possibly use, whether the modules
> use them or not. With Apache 1.3, the general rule seemed to be that if
> you wanted to take advantage of a given modules, you needed to go out and
> get the libraries it required first. Why did we get away from that
> mind-set?
Why do we include PCRE? Why do we include APR? As a convenience for our
users. They can download a single distro and be up and running. As we
increase our functionality, and the functions that people will typically
want to use, then we'll be doing a bit of packaging.
> Are we at least not building SDBM if none of the modules being built need
> it?
It is only built when $apache_need_sdbm gets set. At the moment, this is
only set by the config script in dav/fs/. If you're seeing it get built when
dav_fs is not selected, then a bug exists (and I'll fix it).
> How does this interact with the other modules listed above? When we added
> expat, we broke mod_perl at least, and possibly other modules that were
> using expat. By adding SDBM, are we breaking any of the modules that have
> their own SDBM interface?
I'm not too clear on the Expat issue that person sent in. I'll need to
investigate, but that was the only time that we've heard about it here. I
wonder if that person had a local config problem or whether it is a common
problem.
[ checking mod_perl list archive ]
Yes, there are problems -- XML::Parser::Expat exports the XML_ symbols which
conflict with those exported by Apache. Doug has altered mod_perl to built
Apache with --disable-rule=expat unless/until the XML::Parser::Expat
maintainer stops exporting those symbols (Clark Cooper). The ideal situation
is to have a libexpat.so which gets used, rather than exporting from Apache.
But even if we do that, the XML::Parser::Expat is still going to have
problems because it would export the XML_ symbols and conflict with the
libexpat.so.
Re: SDBM. Perl directly includes SDBM also. I'm not clear on what kind of
conflict may occur between this and Perl when it is loaded via mod_perl; it
looks like both are namespace-protected with sdbm_.
-----------
Much of this can be ameliorated by the ap_dbm_ stuff that is in STATUS and
the mod_dav integration notes. We can then select and use any available
database in the OS (GDBM, BSD DB, or NDBM). If we can't find anything
useful, then we fall back to the SDBM library.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: src/lib/sdbm
Posted by Tony Finch <do...@dotat.at>.
Greg Stein wrote:
>
>We definitely want to continue crediting the original author(!), but we can
>now APR-ize the bugger for portability; make it use pools; improve the
>file-locking semantics; etc.
I can see no good reasons for making sdbm use pools and a big disadvantage
(memory leaks).
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
476 tarpaper in the tissue dispenser
Re: src/lib/sdbm
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jul 13, 2000 at 03:04:02PM -0500, William A. Rowe, Jr. wrote:
>
> Given that there is no xdbm native library on Win32 and probably
> some others, I appreciated that we are going to build a baseline
> xdbm into Apache.
>
> This follows the same philosophy as the expat-lite or whatever
> default regex tool we distribute.
>
> We are fortunate that sdbm doesn't carry the same licensing issues
> that samba or i18nlib require :)
Ooh. Good point.
And licensing: the SDBM that is in our source control is *ours* with *our*
license. One of the things about public domain -- it means that you can
place it under your own copyright and license.
We definitely want to continue crediting the original author(!), but we can
now APR-ize the bugger for portability; make it use pools; improve the
file-locking semantics; etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: src/lib/sdbm
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
Given that there is no xdbm native library on Win32 and probably
some others, I appreciated that we are going to build a baseline
xdbm into Apache.
This follows the same philosophy as the expat-lite or whatever
default regex tool we distribute.
We are fortunate that sdbm doesn't carry the same licensing issues
that samba or i18nlib require :)
Bill
> -----Original Message-----
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Thursday, July 13, 2000 11:18 AM
> To: new-httpd@apache.org
> Subject: src/lib/sdbm
>
>
>
> >From STATUS:
>
> * add SDBM into src/lib/sdbm/ as a default/fallback DBM
> implementation.
> SDBM is used by Perl, mod_dav, mod_sssl, others for basic DBM
> support.
> Status: Greg +1 (volunteers)
>
> Are we actually including SDBM with Apache now? Why don't we
> just provide
> an interface to it? It seems that with Apache 2.0, we are
> including all
> of the libraries that Apache could ever possibly use, whether
> the modules
> use them or not. With Apache 1.3, the general rule seemed to
> be that if
> you wanted to take advantage of a given modules, you needed
> to go out and
> get the libraries it required first. Why did we get away from that
> mind-set?
>
> Are we at least not building SDBM if none of the modules
> being built need
> it?
>
> How does this interact with the other modules listed above?
> When we added
> expat, we broke mod_perl at least, and possibly other modules
> that were
> using expat. By adding SDBM, are we breaking any of the
> modules that have
> their own SDBM interface?
>
> Ryan
>
> ______________________________________________________________
> _________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------
> -----------------
>
>