"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> >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?
I see someone already told you about svn_pool_clear(). :-)
By the way, for those interested in reading about our "best pool
practices" philosophy, take a look at Subversion's HACKING guidelines
-- at the section called "APR pool usage conventions". These are the
magic formulas that we'd like to spread into mod_dav:
http://svn.collab.net/repos/svn/trunk/HACKING
> >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.
We don't want to force Subversion to depend on the httpd-2.1 branch.
Our policy (for simplicity and stability) is that every release of
Subversion is guaranteed to build/run against the latest stable
release of httpd. As Subversion gets closer and closer to 1.0
stability, it's important that we're not forcing users to checkout
bleeding-edge httpd and apr.
> >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?
This is Greg Stein's department; I'm not familiar with the political
implications of our various options. ("Do we make v1 and v2 provider
interfaces available to the 2.0 branch? Or just declare that mod_dav
has a new API in httpd-2.1?") I'll let him address this topic.
But at the moment, it's outside the scope o our immediate goals to
drag every mod_dav_* backend kicking-and-screaming into a new v2
interface. We just want to make mod_dav use pools efficiently in
httpd-2.0, and that's a relatively short-term project.
