On 25 Jun 2011, at 21:11, Graham Leggett wrote: > This is not so, to fix this, you would need to wrap every single LDAP API > function call[1] in an optional function, and if you did that, you would > solve the problem that caused you to want to remove apr_ldap from APR in the > first place, making the whole exercise pointless - you may as well just have > fixed apr-ldap in place.
In view of the escalation of this argument, I'm trying to review the history and see if I can get to grips with the underlying problem. It seems this is where your objection starts, right? If it matters, I'm trying not to take sides here, and I too find it uncomfortable when Bill gets abrasive in a public list. But isn't the above a slight misstatement of the issue? ap_ldap (and apr_ldap before) wraps only a subset of the LDAP API, that subset is what in fact has to be wrapped in optional functions. I don't see a problem with that: more optional functions can be introduced as and when more APIs are exposed. And optional functions can exist alongside regular API functions, as in mod_dbd.h, as and when you or anyone do it. > The timing cannot be worse - an already suboptimal API plus these new bugs > are being dumped into httpd in the final stages of trying to bake the final > version of httpd v2.4.0, which means we will be stuck with this brokenness > through the life of httpd v2.4. Up to a point. We're full of compromises, some nicer, some uglier. But what *new* bugs are you referring to that aren't fixed by optional functions? Would it make sense to introduce a mod_dbd-like parallel API, and does it break anything that would prevent you hacking it within the lifetime of 2.4? > There is no need for this move at all, as httpd works perfectly against APR > v1.x (or did until this change). APR v2.x hasn't gone through any kind of > stabilisation phase, never mind seen an alpha or beta release, and so httpd > v2.4.x being compatible with apr-trunk at this stage is not necessary, > especially seeing that when httpd v2.4 is released, it's API is set in stone, > but APR v2.0's API remains in flux. Or to put it another way, the fact that > apr_ldap is missing from apr-trunk is not a problem for httpd v2.4, and can > be solved after httpd v2.4. That's a fair point. If you can convince me there are NEW unsolved bugs, I may support it. But I wouldn't agree with excluding APR2 use if these new bugs are (no more than) what optional functions solve. Nor do I think now is the right time to make an issue of defects that are equally present in ap_ldap and in apr_ldap before. > I am therefore vetoing this move of apr_ldap from APR to httpd. Hang on! How long ago did this move happen, and when did you first raise concerns? -- Nick Kew Available for work, contract or permanent http://www.webthing.com/~nick/cv.html
