httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [Fwd: [dav-announce] Release: mod_dav 0.9.6-1.3.4]
Date Sun, 31 Jan 1999 11:44:26 GMT
Ralf S. Engelschall wrote:
> ...
> The "needs a maintainer inside the AG" issue should be no too big problem as
> long as the source is _very_ clean, I think.  My current main problem is
> really the size: mod_dav is tiny,

It will grow as the other DAV specs finalize (Advanced Collections,
DASL, and Versioning). There is also the Class 2 DAV compliance from the
base-level DAV spec that I haven't completed (Class 2 deals with

However, you're right about this next part -- external packages
definitely make it "bigger" than any simple source code linecount issue.

> but it needs Expat and GDBM, i.e. two
> external packages. This makes it a little bit balky to be easily compile-able
> inside the source tree. So, I see two reasonable possibilies:
> 1. Let it integrate seamlessly into the source tree:
>    - move from GDBM to plain NDBM or at least support
>      NDBM in addition to GDBM as a fallback.

I think there was an issue with NDBM, but I can reexamine. The 0.9.7
release will include SDBM (a public domain DBM). SDBM is also shipped by
Perl, so it should be capable enough. SDBM will become the default
linkage -- GDBM cannot be the default because it is GPL (not even

>    - strip down Expat to a libexpat which can be included it into the source
>      tree (e.g. under src/expat/). That's reasonable because other modules
>      then can use this nice XML parser library, too. Let the compilation of
>      this library triggered by a "Rule EXPAT=yes". Expat is under the MPL I
>      think, right?

Expat is MPL, but has recently picked up an option for electing to use
the GPL instead. The MPL 1.0 is "undesirable" for Apache, and GPL is
incompatible. Once MPL 2.0 comes out, then it may be okay to package
with Apache.

If Expat is determined as compatible with Apache, then it can certainly
be stripped down. I believe there are only a dozen relevant files. I
will investigate creating an Expat library for Apache, along the
src/expat/ line that you suggest. Despite any compatibility issue, it
could be a nice choice for "third party" modules.

Regardless, I've already received interest from a company that doesn't
like the MPL, so they want to build in an option to use other XML
parsers. This may be an approach for Apache/XML integration.

>    - let mod_dav reside inside src/modules/dav/ and let the
>      libdav.module force the EXPAT rule and determine the
>      DBM library as other modules do.
>    This way mod_dav has only the DBM library requirement and for most of the
>    platforms this means nothing special.  So, mod_dav is less bulky to build.

Okay. I'll look into how this is done by the other modules. Thanks for
the pointers!

> 2. Alternatively let libdav.module at least configure itself
>    with variables like GDBM_BASE and EXPAT_BASE, i.e.  let it search the
>    libgdbm/gdbm.h and libexpat/xml.h files under those locations when they
>    cannot be find under standard locations. This way it's at least possible to
>    build src/modules/dav/ without editing any Makefiles, etc.

Will do, with the license caveats mentioned above.

> I think because 2.) is no problem, you should do this anyway.  But for a
> possible inclusion into the source tree, 1.) sounds reasonable to me.
> And finally a little bit of feedback for mod_dav 0.9.6:
> In libdav.module you "RULE_HIDE=yes"? This sounds useless to me,
> because there is no such rule neither inside Apache nor mod_dav.

Cut/paste. Some other module had that line, or I read it in a doc
somewhere. I'll torch it. Thanx.
[ looks like I also have a bunch of reading up (code and/or doc) to do
on the .module files :-) ]

Quick question: with all this fancy rule stuff going on, will this
effectively mean that APXS will no longer be usuable for mod_dav?


Greg Stein,

View raw message