httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject mod_dav integration
Date Mon, 26 Jun 2000 00:32:47 GMT
While the filtering stuff is at its current review point, I've got a bit of
time to detail how I would like to integrate mod_dav into the Apache 2.0

First order of business, though: I was asked to join the ASF to do this
integration (and gladly accepted), but as it is a new (reasonably-sized)
feature, it needs to passed by people for a vote. I know there are at least
three +1 votes for it, so please speak up if you have a veto.

Second: mod_dav is quite stable, after its long development period. I'm
quite comfortable just dropping it in and doing the 2.0 port, followed by
some APR-ization. Reviews of the code are happily accepted, of course, but I
believe most of the issues are really going to be about code organization
rather than other items.

Third: if there *are* technical issues with the code, then I would ask that
we fix them after the checkin. I'd like to be able to check in a pure copy
of the mod_dav 1.0 code and then to build up the necessary/requested changes
the CVS history. Of course, if there is something just too awful :-), then
we'll fix it first.

Okay... the integration. I think the best way is to list each of mod_dav's
files, their purpose, and where I believe they should go into Apache 2.0.

  the main module. implements the DAV methods, Apache hooks, and manages
  Location: src/modules/dav/main/mod_dav.c
  Near term: src/main/http_core.c picks up the "LimitXMLRequestBody"

  Main header file defining a ton of mod_dav structures, functions, types,
  and other stuff.
  Location: src/modules/dav/main/mod_dav.h
  Future extra: src/include/* as certain pieces are extracted as "general"
    Apache functionality

  dynamic module support for mod_dav. this is reasonably bogus stuff that
  I've never been too happy with. I expect to eliminate/replace this design
  using Apache modules and hooks. Until that point, it will reside in the A2
  Location: src/modules/dav/main/dav_dyn.c

  DBM support for storing DAV properties and locks. Can work with GDBM or
  SDBM. This also implements one of mod_dav's "plugin" interfaces. My intent
  is to check this in as a mod_dav plugin and migrate its internals to a new
  Apache DBM facility. dav_fs_dbm would then be a slim cover translating
  between mod_dav's plugin API and the Apache DBM API.
  Location: src/modules/dav/fs/dbm.c
  Future extra: src/main/util_dbm.c

  Implements mod_dav's "DAV locks" plugin for filesystem-based DAV
  repositories. Uses the DBM stuff to store the locks.
  Location: src/modules/dav/fs/lock.c

  Implements mod_dav's "repository" interface for the filesystem. (mod_dav
  can work against arbitrary repositories; this is the default, which uses
  the filesystem). Also implements the "live property" interface. Will be
  split into a couple files.
  Location: src/modules/dav/fs/repos.c
  Near term extra: src/modules/dav/fs/liveprop.c

  Private header for the filesystem-based providers.
  Location: src/modules/dav/fs/repos.h

  Utilities for dealing with DAV locks. Layers functionality over that
  provided by the locking plugin.
  Location: src/modules/dav/main/util_lock.c

  Implements UUID generation and the DAV "opaquelock" locktoken scheme.
  These should be split up, and it should migrate to use APR's random number
  Location: src/modules/dav/main/opaquelock.c
  Future extra: src/main/util_uuid.c

  Header for the prototypes for the functions in dav_opaquelock.c
  Location: integrated into mod_dav.h
  Future extra: src/include/util_uuid.h (?)

  Deals with DAV properties, layering over the "dead prop" and "live prop"
  plugin APIs.
  Location: src/modules/dav/main/props.c

  Various utility functions to support mod_dav. Some of these will float out
  into Apache core.
  Also contains processing for the "If:" header, which should be combined
  into the other If-* header processing somewhere.
  Location: src/modules/dav/main/util.c

  Additional utility layer over the Expat parser, mapping Expat's "event"
  interface into a simple tree structure.
  Location: src/main/util_xml.c
  Also: src/include/ap_xml.h -- contains XML-related items extracted from

  The SDBM library. Public domain, stable, includes changes incorporated
  from Perl and mod_ssl. Also, specific to mod_dav are some additions to use
  file locks for exclusive access.
  Location: src/lib/sdbm/

Any file not mentioned above will not be integrated. Configure/build support
will need to be created, and documentation will need to be extracted from
the various mod_dav doc items.

Careful observers :-), will noticed the following new directories:


Of particular interest is that modules/dav/main/ is the core module and can
be compiled out of the server (default will be "enabled"). modules/dav/fs/
is the default set of providers. The directory layout provides for
modules/dav/mysql/ and similar providers. Brendan Quinn has already
published a first draft for a MySQL provider; there have also been private
implementations of providers for a commercial RDBMS, for Rational's
ClearCase, and for CORBA. The dir structure provides for including these
other varieties in our tree. Third parties should be able to create a
provider as a standard Apache module (this is part of why I dislike dav_dyn
and want to axe it asap).

Note that mod_dav implements "repository independence" through these
plugins. Another term is "Virtual File System", although that is a bit of a
misnomer, as the APIs are a bit more HTTP-centric ("resources" rather than
files; knowledge of HTTP headers; etc). I would like to see the VFS stuff
become a "true, core" feature, rather than available only with mod_dav
enabled. I would expect to shift those features out of mod_dav over time and
into the core. However, I don't have any plans for that today, and won't
suggest them at this time. That will be another "feature" for the core and
will be subject to further discussion :-)

I think that is about all that I can think of. I would like to perform the
integration later this week. Please pipe up with questions, concerns,
commentary, etc "soonish".


Greg Stein,

View raw message