httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: mod_dav overhaul
Date Wed, 28 May 2003 19:15:18 GMT
At 01:12 PM 5/28/2003, you wrote:

>Hi, I'm a new subscriber to this list, but not a complete stranger
>either.

Hi Ben... around here you are no stranger than most :-)

>I'm writing because I plan to do some major overhauling of mod_dav.

Comments inline, but kudos for taking this on...

>1. revamp mod_dav's use of pools internally.
>
>   This means adding pool arguments to the various "layers" of
>   function calls within mod_dav.  Each caller controls subpool
>   creation, and possibly passes a subpool into a subordinate function
>   call.  Whereever there are loops that allocate temporary memory, we
>   use (and *clear*) a subpool within the loop.  These changes are
>   made up to the point of the provider backend;  but we halt there,
>   and do not pass pools into provider callbacks.

It makes me wonder... today we have to create and destroy the pool.
But what about reuse?  The overhead of creating the pool itself?  It seems
like a good extention to the apr_pool api if we had an apr_pool_recycle
function that would do the usual pool cleanups and frees, but let us reuse 
the pool's own memory without getting tangled in thread locking.  For any
symmetrical use of pools (where each recycle is generally similar in footprint
to the prior allocations) this could be pretty sweet.

Just food for thought.

>2. make all mod_dav_svn callbacks take pools.  But then we wrap these
>   callbacks with wrappers that *don't* take pools, so mod_dav_svn can
>   still plug-in to mod_dav.

Why - in the sense that httpd-2.1 forward breaks binary compatibility?
Wouldn't it make more sense to extend mod_dav_svn (and other dav
backends) going forward?  We aren't troubling ourselves with that sort
of compatibility for httpd-2.2, in that we will just get the API 'right' as
of each major/minor bump.  That means code must be 'adjusted' for
the next release anyways.

>3. use the API versioning which is present in httpd-2.0 (and later) to
>   define two back-end interfaces for mod_dav. The current interface
>   is v1, and the new "pool accepting" interface becomes v2.  mod_dav
>   is updated so that it can use either interface.  mod_dav_svn is
>   updated to supply both: the old wrapper-based form, and the new
>   form. This will allow a mix/match between httpd-2.0.X (and 2.X.Y)
>   and mod_dav_svn.

I'm mostly asking, is this a real win?

>4. we can eventually backport these changes from httpd-2.1 to the
>   httpd-2.0 branch;  it still maintains compatibility with v1
>   providers, such as mod_dav_fs.

If we care to.  OTOH, by the time various refactorings are done sometime
in the late summer or early autumn, it will be time for httpd-2.2 and our
beloved httpd-2.0 will be in maintenance mode.  Unlike the 1.3 -> 2.0
move, we don't expect oodles of new instability.

One more thought for your plate; we can start pulling off httpd-2.1 alpha
developer tarballs anytime someone shouts 'I'll RM it!'  This could be very
good for getting the 'v2' flavor into early adopter's hands (e.g. svn dev folk.)

Best 'o luck, and please make certain we really use decent error code
handling, I know I refactored some of that, but I don't remember if I ever
finished it entirely.

Bill



Mime
View raw message