httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: mod_dav integration
Date Mon, 26 Jun 2000 17:09:55 GMT
SDBM is the only add-on piece in mod_dav. As I mentioned, it is "Public
Domain". That means there isn't even a copyright on the thing. Which in turn
means, that we just slap the ASF license onto our version of SDBM.

[ I say version because I'd like to see it APR'ized, and we don't need to
  follow any external development (it was written a decade ago and has since
  had all bugs removed). ]

The rest of mod_dav will be owned by the ASF, so it will have the standard
ASF license.

Cheers,
-g

On Mon, Jun 26, 2000 at 10:13:15AM -0400, Bill Stoddard wrote:
> Greg,
> What license are the add on pieces (SDBM, etc,)  under? You say 'public' but GPL is
> public. Can you be more specific?
> 
> +1 on this plan provided there are no nasty license issues.
> 
> Bill
> 
> 
> > 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
> > tree.
> >
> > 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.
> >
> > mod_dav.c:
> >   the main module. implements the DAV methods, Apache hooks, and manages
> >   configuration.
> >   Location: src/modules/dav/main/mod_dav.c
> >   Near term: src/main/http_core.c picks up the "LimitXMLRequestBody"
> >     directive.
> >
> > mod_dav.h:
> >   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
> >
> > dav_dyn.c:
> >   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
> >   tree.
> >   Location: src/modules/dav/main/dav_dyn.c
> >
> > dav_fs_dbm.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
> >
> > dav_fs_lock.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
> >
> > dav_fs_repos.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
> >
> > dav_fs_repos.h:
> >   Private header for the filesystem-based providers.
> >   Location: src/modules/dav/fs/repos.h
> >
> > dav_lock.c:
> >   Utilities for dealing with DAV locks. Layers functionality over that
> >   provided by the locking plugin.
> >   Location: src/modules/dav/main/util_lock.c
> >
> > dav_opaquelock.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
> >   facilties.
> >   Location: src/modules/dav/main/opaquelock.c
> >   Future extra: src/main/util_uuid.c
> >
> > dav_opaquelock.h:
> >   Header for the prototypes for the functions in dav_opaquelock.c
> >   Location: integrated into mod_dav.h
> >   Future extra: src/include/util_uuid.h (?)
> >
> > dav_props.c:
> >   Deals with DAV properties, layering over the "dead prop" and "live prop"
> >   plugin APIs.
> >   Location: src/modules/dav/main/props.c
> >
> > dav_util.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
> >
> > dav_xmlparse.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
> >     mod_dav.h
> >
> > sdbm/:
> >   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:
> >
> >   src/lib/sdbm/
> >   src/modules/dav/
> >   src/modules/dav/main/
> >   src/modules/dav/fs/
> >
> > 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".
> >
> > Thanx!
> > -g
> >
> > --
> > Greg Stein, http://www.lyra.org/

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

Mime
View raw message