httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: mod_custom_log exits too late?
Date Tue, 17 Sep 2002 14:56:52 GMT
On 17 Sep 2002, Brian Pane wrote:

> On Mon, 2002-09-16 at 23:32, Justin Erenkrantz wrote:
> > On Mon, Sep 16, 2002 at 09:46:47AM -0700, Brian Pane wrote:
> > > I disagree entirely.  There's no need to let the API keep changing
> > > continuously, especially not for the sake of "correctness."  All of
> > > our competitors provide API stability.  And as a result, people who
> > > develop modules for, say, IIS or IPlanet don't need to worry about
> > > their code breaking with every maintenance release.
> > 
> > I think you're missing a huge point here.
> > 
> > You *cannot* tell IIS or iPlanet that their APIs suck.
> Of course you can.  And if you're a big enough customer, your
> server vendor will take your comments seriously enough to improve
> APIs in the next major release.  What a responsible vendor will
> not do, however, is break all their other customers' systems in
> the next maintenance release just because one customer didn't like
> the function signatures.
> > You probably
> > can't even fix problems in their servers.  You're stuck.
> > 
> > You *can* tell us that our APIs suck and provide patches on ways to
> > improve - especially for 2.0.
> Sure.  And we have an obligation to users and third party developers
> to take constructive input and work it in to future releases in a
> manner that won't break people's systems.

I don't think we are going to end up agreeing.  I also don't think it
matters.  The reality is that you can't get to binary compat without doing
1 of two things.

1)  Wait until the API is ready.
2)  Litter the API with multiple functions that all do the same thing in
slightly different ways.

#2 is bogus, and all it does is to make the API harder to understand.  If
you can somehow manage to acheive binary compat without doing either of
these, then cool.  Otherwise, I would much rather see us choose option #1,
becuause it is less detrimental in the long run.

The example that has been given so far, is the ap_filter_*_register
functions, which had a function pointer added.  The suggestion was that
this could have been done by adding another function.  Yes, it could
have.  But, you wouldn't be able to get rid of those functions until
3.0.  As proof, we had functions from 1.2 that weren't removed until the
2.0 release.  Sorry, but API pollution doesn't excite me.  Between API
pollution and breaking binary compat, I choose the latter.  

Commercial companies can't do this, because users don't have the
source.  Our users do, and we can do this.  If a commercial company wants
to modify Apache to provide binary backwards compat, they can do that, and
as long as they remain within a single major version, the work shouldn't
even be that hard.

The other option, is for us to create an ap_compat.h header again.  This
would provide us with a level of source compat.  I don't know why we
haven't been keeping that file up to date.


Ryan Bloom               
550 Jean St
Oakland CA 94610

View raw message