On Mon, Nov 11, 2002 at 01:51:52PM -0600, Karl Fogel wrote:
> "Ich Selbst" <ichselbst@gmx.ch> writes:
>...
> > >I think an svn_initialize() would make sense when it would do more
> > >than just wrap apr_initialize(). But right now, that's all it would
> > >do; the body of the function would literally be one line long.
> >
> > Yes, right now it would be one line long. But think about the
> > possibility that subversion one day needs more libraries which
> > also need initialization. Then the subversion API wouldn't need
> > to change and probably clients would also not necessarily need
> > a change...
>
> True, though if that day doesn't arrive before 1.0, I have doubts it
> will ever arrive... However, if you want to work up a patch, that
> would be great. 'svn_initialize' is great, but I'd say put it in
> svn_pools.h, since there's no other obvious place for it, and it at
> least has something to do with pools. And patch the HACKING file as
> well, of course.
I think it would be a mistake to have our libraries initialize APR. We
*take* a pool. Thus, for an app to give us a pool, they must get it from
APR. To get it from APR, they need to initialize APR.
Blame APR docs, but don't add initialization to SVN. What happens to apps
that also use APR? Gee.. like 'svn' ? You don't want multiple
initializations (one from the app, and one from svn_initialize).
Nah... we're a library and we take APR inputs. The caller is responsible for
the initialization to give us that; not us.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 12 05:51:30 2002