Re: svn commit: r799085 - /apr/apr/trunk/apr-config.in

[Ruediger Pluem <rp...@apache.org>]

On 07/29/2009 11:29 PM, wrowe@apache.org wrote:
> Author: wrowe
> Date: Wed Jul 29 21:29:42 2009
> New Revision: 799085
> 
> URL: http://svn.apache.org/viewvc?rev=799085&view=rev
> Log:
> Drop incomplete abstrations from apr-2.0; for today, simply omit the ability
> to inspect ldap linkage binding.
> 
> apr_ldap either needs to be refactored as a proper abstration or dropped from
> the apr 'suite' of portability abstractions, as previously discussed on list.
> This commit might encourge some forward progress to accomplishing this.
> 
> Note there is nothing wrong with abstracting our build/autogunk m4 macros
> to the point where authors can borrow the logic when they want an apr-ish
> method of picking one of many interfaces.
> 
> Modified:
>     apr/apr/trunk/apr-config.in

This breaks compilation of httpd trunk with apr trunk if you want to compile
the httpd ldap modules.

Regards

Rüdiger

Re: svn commit: r799085 - /apr/apr/trunk/apr-config.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
> 
>> The LDAP proponents have all agreed over a year ago that this should be
>> done.
> 
> Exactly, and that hasn't changed since then.
> 
> Right now I am ENOTIME in a big way - I have lots of changes to make to
> other components right now, and my accountant needs to be made happy.
> The big-LDAP-fix is going to need a solid block of my time, and that is
> not going to happen until after August is finished.
> 
> Your change just made my job even harder, because I would have first
> needed to reverse engineer why the LDAP build broke, picking through our
> custom apr-specific build scripts to isolate the file that changed, and
> then follow the history to find out why.

The apr_ldap build has not broken.

Consumers who expected apr to provide libldap bindings are missing -lldap
(-llber) now.  That is easily remedied by those who want to play with such
things.

Re: svn commit: r799085 - /apr/apr/trunk/apr-config.in

[Graham Leggett <mi...@sharp.fm>]

William A. Rowe, Jr. wrote:

> The LDAP proponents have all agreed over a year ago that this should be
> done.

Exactly, and that hasn't changed since then.

Right now I am ENOTIME in a big way - I have lots of changes to make to
other components right now, and my accountant needs to be made happy.
The big-LDAP-fix is going to need a solid block of my time, and that is
not going to happen until after August is finished.

Your change just made my job even harder, because I would have first
needed to reverse engineer why the LDAP build broke, picking through our
custom apr-specific build scripts to isolate the file that changed, and
then follow the history to find out why.

Regards,
Graham
--

Re: svn commit: r799085 - /apr/apr/trunk/apr-config.in

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Graham Leggett wrote:
> Ruediger Pluem wrote:
> 
>>> URL: http://svn.apache.org/viewvc?rev=799085&view=rev
>>> Log:
>>> Drop incomplete abstrations from apr-2.0; for today, simply omit the ability
>>> to inspect ldap linkage binding.
>>>
>>> apr_ldap either needs to be refactored as a proper abstration or dropped from
>>> the apr 'suite' of portability abstractions, as previously discussed on list.
>>> This commit might encourge some forward progress to accomplishing this.
>>>
>>> Note there is nothing wrong with abstracting our build/autogunk m4 macros
>>> to the point where authors can borrow the logic when they want an apr-ish
>>> method of picking one of many interfaces.
>>>
>>> Modified:
>>>     apr/apr/trunk/apr-config.in
>> This breaks compilation of httpd trunk with apr trunk if you want to compile
>> the httpd ldap modules.

Yes.  This behavior is by design.

> Which is in turn a prerequisite for anyone wanting to develop the ldap
> stuff further. Please revert.

Anyone wanting to develop and ldap abstraction is welcome to do so!!!

You hit the nail on the head.  The previous api is "ldap stuff".  As in,
we want more stuff.  The problem is, until we start cleaning up and
arranging the stuff, we will not get anywhere.

Anyone wanting apr-util ldap library detection .m4 code, can borrow that.
It's under Apache License.  They can do so now and refresh whenever, just
as they can borrow our own recommended apr library detection code.

> This change only makes sense to do if apr-2.0 becomes ready for actual
> release, and we're not anywhere near there yet.

Right, we can't release 2.0 because it's namespace is not clean, because
things such as raw ldap bindings are still provided, and that isn't APR's
job (refer to all other APIs for similar issues).

The LDAP proponents have all agreed over a year ago that this should be
done. There was absolute refusal initially, until the benefit of plugging
in alternate ldap providers/SDKs became interesting and solving many
'unexpected' results and return codes (bugs) became an issue.

apr-2 is, as you say, nowhere near release for a month or few.  So in the
meantime, the developers who would be helping to make it ready need to be
prepared for what changes, and this changes.  Those who need ldap right now
to transition ldap to apr as they develop the ldap api know how to -lldap.

The technical veto is that the module which allocates resources must have
the corresponding interfaces to release them.  Right now ldap resources
are allocated by ldap and apr_ldap, and freed by apr_ldap and the consumer.
This is not good.

But that's my argument.  We will settle with a vote.

Bill

Re: [VOTE] apr_ldap 2.0 support (was r799085)

[Guenter Knauf <fu...@apache.org>]

William A. Rowe, Jr. schrieb:
>   [x] apr 2.0 must support a complete ldap interface
>       (revert r799085 for now, reapply upon 2.0.0 release,
>       or rm ldap/ if not completed)

I think it would be useful for developers (specially also for external
developers as consumers of APR) to have a LDAP.STATUS file (or
LDAP.TODO) where the points in detail we expect to be done to make it
complete would be listed; this would also explain to external developers
whats currently lacks with the LDAP support.

Gün.

Re: [VOTE] apr_ldap 2.0 support (was r799085)

[Graham Leggett <mi...@sharp.fm>]

William A. Rowe, Jr. wrote:

>   [X] apr 2.0 must support a complete ldap interface
>       (revert r799085 for now, reapply upon 2.0.0 release,
>       or rm ldap/ if not completed)

There is no point making it more difficult for the LDAP people to get
this work done.

If we are ready for a v2.0.0 release, then this makes sense. Not before.

Regards,
Graham
--

Re: [VOTE] apr_ldap 2.0 support (was r799085)

[Ruediger Pluem <rp...@apache.org>]

>   [+1 ] apr 2.0 must support a complete ldap interface
>       (revert r799085 for now, reapply upon 2.0.0 release,
>       or rm ldap/ if not completed)


Regards

Rüdiger

Re: [VOTE] apr_ldap 2.0 support (was r799085)

[Ruediger Pluem <rp...@apache.org>]

On 08/12/2009 11:03 PM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>> Is this vote over or should we wait for further votes?
>> Please find the current results below
> 
> The vote is over.  We will revert, and whenever anyone feels like
> rolling APR 2.0, they may simply svn rm apr/ldap if it has not been
> completed.
> 
> I'm very glad that it attracted four people with some level of
> interest in apr's ldap support.  I've been worried that it was all
> essentially abandonware (and it might be) but to have this many who
> express an immediate interest in maintaining support is reassuring.
> 
> Thanks to all who voted.  I cannot revert conveniently, but will do
> so the next time I have connectivity unless someone else beats me to
> it.  Since it was gone a week or two without note, it should be ok
> for the few days it would take me to get back to it.

Ping? Do you have time to revert?

Regards

Rüdiger

Re: [VOTE] apr_ldap 2.0 support (was r799085)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Ruediger Pluem wrote:
> Is this vote over or should we wait for further votes?
> Please find the current results below

The vote is over.  We will revert, and whenever anyone feels like
rolling APR 2.0, they may simply svn rm apr/ldap if it has not been
completed.

I'm very glad that it attracted four people with some level of
interest in apr's ldap support.  I've been worried that it was all
essentially abandonware (and it might be) but to have this many who
express an immediate interest in maintaining support is reassuring.

Thanks to all who voted.  I cannot revert conveniently, but will do
so the next time I have connectivity unless someone else beats me to
it.  Since it was gone a week or two without note, it should be ok
for the few days it would take me to get back to it.

Bill

Re: [VOTE] apr_ldap 2.0 support (was r799085)

[Ruediger Pluem <rp...@apache.org>]

Is this vote over or should we wait for further votes?
Please find the current results below

On 08/05/2009 04:54 PM, William A. Rowe, Jr. wrote:
> Please vote for your choice.
> 
>   [ ] apr 2.0 should support an incomplete ldap interface
>       (revert r799085 for good)

0

>   [ ] apr 2.0 should support a complete ldap interface
>       (revert r799085 for now, reapply if ever completed)

0

>   [ ] apr 2.0 must support a complete ldap interface
>       (revert r799085 for now, reapply upon 2.0.0 release,
>       or rm ldap/ if not completed)

3 (minfrin, rederpj, rpluem)

>   [ ] apr 2.0 must support a complete ldap interface
>       (do not revert r799085!  rm ldap/ if not completed)

1 (wrowe)

>   [ ] apr 2.0 should should drop ldap support completely
>       (please rm ldap/ already)

0

> 
>   [ ] I don't care

0

Regards

Rüdiger

Re: [VOTE] apr_ldap 2.0 support (was r799085)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

>   [X] apr 2.0 must support a complete ldap interface
>       (do not revert r799085!  rm ldap/ if not completed)

[VOTE] apr_ldap 2.0 support (was r799085)

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Please vote for your choice.

  [ ] apr 2.0 should support an incomplete ldap interface
      (revert r799085 for good)
  [ ] apr 2.0 should support a complete ldap interface
      (revert r799085 for now, reapply if ever completed)
  [ ] apr 2.0 must support a complete ldap interface
      (revert r799085 for now, reapply upon 2.0.0 release,
      or rm ldap/ if not completed)
  [ ] apr 2.0 must support a complete ldap interface
      (do not revert r799085!  rm ldap/ if not completed)
  [ ] apr 2.0 should should drop ldap support completely
      (please rm ldap/ already)

  [ ] I don't care

Re: svn commit: r799085 - /apr/apr/trunk/apr-config.in

[Graham Leggett <mi...@sharp.fm>]

Ruediger Pluem wrote:

>> URL: http://svn.apache.org/viewvc?rev=799085&view=rev
>> Log:
>> Drop incomplete abstrations from apr-2.0; for today, simply omit the ability
>> to inspect ldap linkage binding.
>>
>> apr_ldap either needs to be refactored as a proper abstration or dropped from
>> the apr 'suite' of portability abstractions, as previously discussed on list.
>> This commit might encourge some forward progress to accomplishing this.
>>
>> Note there is nothing wrong with abstracting our build/autogunk m4 macros
>> to the point where authors can borrow the logic when they want an apr-ish
>> method of picking one of many interfaces.
>>
>> Modified:
>>     apr/apr/trunk/apr-config.in
> 
> This breaks compilation of httpd trunk with apr trunk if you want to compile
> the httpd ldap modules.

Which is in turn a prerequisite for anyone wanting to develop the ldap
stuff further. Please revert.

This change only makes sense to do if apr-2.0 becomes ready for actual
release, and we're not anywhere near there yet.

Regards,
Graham
--