apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <...@apache.org>
Subject Re: [RFC] Is removal of the LDAP feature from APR trunk veto-able?
Date Sat, 09 Jul 2011 18:10:13 GMT
On 8 Jul 2011, at 20:43, Jeff Trawick wrote:

> Here's one attempt at approaching the question of features and
> veto-ability.  This is of course just my
> understanding^H^H^H^H^H^H^Hopinion.

Thanks for opening this, abstracted from current disagreements.

> The presence of most features in APR is highly subjective.  I.e.,
> there's no technical requirement for APR that says it must or must not
> have the LDAP or memcached or various other features.  Whether or not
> it is present is not veto-able.  The group of developers must
> collectively agree on the feature set.

Presence or absence both not veto-able?  Not entirely convinced
that's meaningful, unless we reformulate to refer to addition/removal
of features - i.e. changes to the status quo.

> The manner in which an APR feature is implemented has a handful of
> technical characteristics which should be met.  Incompatibility with
> the basic technical characteristics is veto-able.  Providing a feature
> which uses a different memory management mechanism or different kind
> of programming interface or a mixture of APR and non-APR programming
> interfaces are examples of technical characteristics which are
> objectively incorrect.
> APR versioning rules place specific restrictions w.r.t. version
> boundaries on removals of features which don't meet requirements or
> additions of features which do.  Breaking any of the versioning rules
> while adding or removing features is veto-able.


Maybe this wants a hypothetical question.  Suppose I want to introduce an
HTML parser to APR.  Assuming I make it technically a good fit, what
threshold of acceptance would I need to pass to introduce apr_html module,
and what would someone opposed to it need to veto it?

> LDAP specifically:
> Deficiencies in the LDAP interface were identified and not addressed
> over a large period of time.  The group of developers sharing an
> opinion made clear the required technical corrections which must be
> made in order for the LDAP feature could remain for APR 2.0.  In fact
> this was a compromise position, compared with the more extreme and
> well supported position of removing it entirely instead of fixing it.
> No APR developer besides Graham was aware of any progress on
> correcting the deficiencies over that time.

Wasn't the primary argument against apr_ldap that it failed to add any
real value to using LDAP APIs directly?  Incompleteness against some
reference API is neither here nor there: many APR modules provide
very limited [foo] APIs compared to a native [foo] library.

> The presence of LDAP in trunk without correction was veto-able.  The
> removal of LDAP in trunk was not veto-able, as it merely was the
> default resolution to satisifying the technical objections expressed
> previously.  Importantly, removing it from trunk didn't prevent the
> deficiencies from being corrected.  (But we can't go down this path
> far without consideration of httpd actions, since httpd is the one
> identified user.)

Not sure I'd agree with that.  Once it's made it as far as a release version
then shouldn't it be changes to that status quo that are veto-able?

But maybe I'm failing to grasp the magnitude of apr_ldap defects.

BTW, some years back I wrote a couple of HTTPD modules for a .edu
client, using apr_ldap in at least one of them.  I'm sure there are others
floating around that'll need updating.

Nick Kew

Available for work, contract or permanent

View raw message