> From: Bill Stoddard [mailto:bill@wstoddard.com]
> Sent: 12 April 2002 22:43
> -----
> > "Bill Stoddard" <bill@wstoddard.com> writes:
> > > -1 (not a veto)
> > >
> > > With the release of a major application (Apache 2.0), the APR API should not change
> unless
> > > there is a compelling reason. This is not a compelling reason.
> >
> > Sure, it can wait, no problem.
> >
> > However, I can see how this situation might start to get painful for
> > APR developers, as more and more applications use APR. Apache 2.0 is
> > just one of N dependents; is there some reason Apache's release
> > process should affect the rate of APR development for everyone?
>
> Breaking API compatability is not something that should be taken lightly. This is an
> issue with all users of APR, not just the http server. I am not against the API changing
> if there is a compelling reason for it. This change is light-years from compelling.
>
> Bill
A few points:
- The GA release of Apache _should_ not restrain APR from doing API changes.
Sure, we can't go changing stuff at random to match which way the wind blows,
but until APR goes 1.0 we should certainly be able to change the API IMO.
- Since the return values are always APR_SUCCESS for the md5 functions
and it is _very_ unlikely that an implementation will need a return value,
this is a valid change. Or at least something to think about. I honestly
don't think there is any code out there checking the return values. Therefor
the change shouldn't affect to many 'users'. However, as Justin pointed out
it is easier to have an API you can make up new return values than having one
with no return values. This seems to be the general policy within APR:
have the API have return values. Even if your implementation always returns
APR_SUCCESS. With this in mind, I second Bill and Justin and like to cast
a negative vote when it comes to changing the md5 API.
Just my $0.02,
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 13 00:53:21 2002