Yeah well, maybe if we'd actually paused an thought before jumping into the
GA we'd be in better shape rather than approaching SNAFU.
david
> -> This is quite an API change - soon after products
> which rely on it have gone GA. Which is a patent
> way to get breakage - and I seen o compelling nee
> From: Bill Stoddard [mailto:[EMAIL PROTECTED]
> Sent: 12 April 2002 22:43
> -
> > "Bill Stoddard" <[EMAIL PROTECTED]> 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 reas
"Bill Stoddard" <[EMAIL PROTECTED]> writes:
> 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
-
> "Bill Stoddard" <[EMAIL PROTECTED]> 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 s
On Fri, Apr 12, 2002 at 03:13:18PM -0500, Karl Fogel wrote:
> "Bill Stoddard" <[EMAIL PROTECTED]> 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.
>
[EMAIL PROTECTED] writes:
> ->We have md5's, md4's, sha1, et.al.
> The all have this structure.
Just talking about the interfaces in apr_md5.h.
Anyway, unless someone is using a vtable to choose which checksum
function to use (?), it shouldn't matter that other interfaces do have
return
"Bill Stoddard" <[EMAIL PROTECTED]> 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 mi
Hmm - some issues:
-> We have md5's, md4's, sha1, et.al.
The all have this structure.
-> I can easily imagine an init of sorts to need to be
able to flag an error at some point.
-> This is quite an API change - soon after products
which rely on it have gon
-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.
Bill
> I'm planning to make the following functions return void instead of
> apr_status_t:
>
>apr_md5_init()
>apr_md5
I'm planning to make the following functions return void instead of
apr_status_t:
apr_md5_init()
apr_md5_update()
apr_md5_final()
apr_md5_encode()
apr_md5() /* this one will get the obvious code tweak too */
They currently can only return success anyway, and it's hard to
conc
On Fri, Apr 12, 2002 at 12:46:19AM -0400, Kevin Pilch-Bisson wrote:
> Not committing, as I can't put it into APR,
This would have made more sense if I had actually cross posted to the
subversion dev list, which keeps a copy of these files that I could have
committed to.
--
I've attached a patch to make find-ap*.m4 look in /usr/local/apache2, since
they are probably the most common places people are going to have apr and
apr-util installed (at least for a while). Plus it saves me some typing on
the configure line :).
Not committing, as I can't put it into APR, and I
12 matches
Mail list logo
