httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <...@engelschall.com>
Subject Re: [Fwd: [dav-announce] Release: mod_dav 0.9.6-1.3.4]
Date Sun, 31 Jan 1999 11:01:07 GMT

In article <36B4192F.5A2CC564@lyra.org> you wrote:

> As I've mentioned before, I would hope that some or all of mod_dav could
> be incorporated into Apache (2.0). I've just updated the license, with
> the 0.9.6 release, to be similar to Apache's. This should make it easier
> to provide mod_dav as part of Ralf's contrib package, or as part of
> Apache itself.

> Ralf provided a list a long while back (Nov 8th) that explained that (at
> least) four features of a module were necessary for integration with
> Apache: stable/clean, license, maintainer within the AG, and size. I've
> got the first two done, but the last two are a bit harder :-). Because
> of the size thing, I believe mod_dav might never become part of the real
> distribution, but I would hope that portions of mod_dav can be
> integrated; both to simplify mod_dav, and to provide similar
> functionality to other modules.

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

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.

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.

                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com

Mime
View raw message