httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: wanting to rev the mod_dav provider API
Date Thu, 20 Jan 2005 18:41:32 GMT
--On Thursday, January 20, 2005 12:23 PM -0600 Ben Collins-Sussman 
<sussman@collab.net> wrote:

> Because mod_dav.h is a public API, it's not clear how I would proceed.
> Especially since we'd want to backport this for a 2.0.x release without
> breaking binary compatibility.
>
> I'd like to know if this process is kosher:
>
>     1. rev the mod_dav provider API in httpd's /trunk
>     2. create new "vtable2" structures in mod_dav.h
>     3. garner votes and backport to 2.0.x
>     4. release 2.0.53, and make svn 1.2 require it.

Yes, this is fine: you'd rev dav_provider to be dav_provider2 and change 
dav_hooks_* as necessary.  I'm not sure that we'd need to bump all of the 
hooks - only those that need specific changes.

Note that we'd need to move dav_lookup_provider/dav_register_provider to 
ap_lookup_provider in mod_dav.c as dav_*_provider doesn't allow the 
versions to be set or queried.

> I'm guessing that in both /trunk and httpd-2.0.53, mod_dav would
> advertise itself as accepting *either* version 1 or version 2 providers.
> mod_dav_fs would still work as a version 1 provider, mod_dav_svn would be
> a version 2 provider.

It doesn't advertise a provider - it just queries for which providers at a 
particular version are associated with the string.  There'll have to be 
some code in mod_dav to essentially act as 'unions' or something to make 
the changes unobtrusive as possible to the rest of the code that hasn't 
changed.

Depending upon your changes, we can bump up mod_dav_fs to a version 2 
provider - if it makes sense for mod_dav_fs.  But, I'll be hesitant to see 
that backported to 2.0.x though.

> (By the way, yes, the backport is necessary.  It's not an option for svn
> 1.2 to use httpd 2.2;  because apr 0.9 and apr 1.0 are
> binary-incompatible, it would break subversion's *own* compatibility
> rules to use apr 1.0 any time before svn 2.0.)

I would focus on getting the changes into trunk first and working to your 
satisfaction.  But, the backport will only happen if we get three +1s - 
yes, that should happen, but I can't guarantee it.  (I'm 1 out of 3.)  And, 
then, we'd have to start a release cycle of 2.0.x.  -- justin

Mime
View raw message