httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: mod_custom_log exits too late?
Date Mon, 16 Sep 2002 17:27:02 GMT
At 12:16 PM 9/16/2002, rbb@apache.org wrote:

>That is the difference between commercial and Open source
>projects.  Commercial projects MUST deal with binary compatiblity, because
>customers expect it, and the software costs money.  Open source projects
>can do "the right thing", and break binary compat when it makes sense to
>do so.

Glad that OS users have such low expectations.

>You can resist them, and you can question if the binary compat breakage is
>required for a specific change, but you cannot force us to provide binary
>compat.  When the code is ready for binary compat, it will just happen.

No, nobody can force this issue.  A vocal subset of the httpd community
can veto arbitrary breakage, offer binary-compatible solutions and workarounds,
and relent when there is no sane way to maintain backwards compat.

>In the meantime, if you try to enforce it, you will end up bloating the
>API.  That is how most commercial ventures provide binary compat, they add
>a new function that is VERY close to an existing function, only the
>prototype is slightly different.  No thanks.

If this is the difference between a signed int and unsigned int, that's one
thing.  Let's take one example, though.

Someone added an arg to allow filter registrations to have an init fn ptr.
An init fn ptr was a great idea.  But there was nothing that said that we
couldn't have a second registration fn to register the init function, instead
of trying to do two things in one call.

The solution that was adopted broke binary compat for a small minority
that needed that feature.  Adding a second function would have eliminated
that breakage and saved module developers one more headache.

I don't suggest we revisit that patch, just that if someone spoke up at
that time, that particular breakage could have been avoided.  As can most
of our breakage on the 2.0 tree from here on, forward.

Bill



Mime
View raw message