On 3/8/07, Ben Collins-Sussman <email@example.com> wrote:
> On 3/8/07, Mark Phippard <firstname.lastname@example.org> wrote:
> > Why don't we just let someone write this as a Subversion feature and let
> > committers decide later if they want to push parts of the framework
> > to APR. It would be disappointing if the only way someone could use
> > feature was if they build Subversion with APR 1.3 or later.
> Why is it disappointing to require apr 1.3 to get a certain feature?
> Why is it a problem at all?
> We already have certain features that require particular versions of
> BDB. Or neon. Or even serf.
Because you are pushing the problem off on the user. We have people that
want builds for Apache 2.2 today. Now, I realize the issue of us providing
Windows binaries is a touchy subject, but in the end we do. Are we going to
provide builds that use the newer APR? Then there is the issue of users of
distros like RHEL which do not provide the latest and greatest versions for
a long time. How easily can they get APR 1.3, without also impacting other
components of their system? I don't know the answer, maybe it is trivial?
Reading the lists over the years, I do not think that is the case though.
In terms of SOC, we could still let them write this as a Subversion feature
and let the committers do the work of refactoring this into APR and holding
it out of trunk until that is completed. I would think if this feature was
going into APR someone (on the Apache side) would want to open the
discussion of whether and when httpd would switch to using it. That would
likely slow down the process of getting it into the official API.
Is the issue the platform-dependent elements? Coudln't we punt on this?
Write a logging API and only provide an implementation that logs to files?
If we log to a file most people can get the rest of what they might want
pretty easily and we could leave it to APR to eventually provide more
Received on Thu Mar 8 20:45:46 2007