On 6/27/2011 8:19 AM, Graham Leggett wrote: > > mod_ldap - An LDAP shared memory cache > mod_authnz_ldap - A user of the LDAP shared memory cache > > The LDAP API exposes way more functionality than mod_ldap exposes, so while > you may have > fixed the problem for the special case that is mod_authnz_ldap, you won't > have fixed the > problem for any other module that makes LDAP calls directly. > > The v1.x LDAP API was removed from APR because it was an incomplete > abstraction, and for > this exact same set of reasons it is inappropriate to add it to httpd. > > Over and above that, given that httpd has no library component common to all > modules > (well, it has, it's called APR), and given that the httpd core is > inappropriate for an > LDAP portability library, the only place to put the LDAP bindings is in > mod_ldap, which > means we either have to accept the module ordering problems that result, or > we have to > create optional functions for every single LDAP API call, and if we do that, > we end up > solving the reason apr_ldap was removed from APR in the first place.
This is precisely the reason that you are wrong. Only mod_ldap and mod_authnz_ldap (and apparently mod_vhost_ldap) need functionality of these helpers (hard to call it an API, since it doesn't actually expose LDAP functionality). If no other module of, nor httpd itself, needs ldap then none should bind to ldap libraries. Of course, following Joe's commit, we no longer have the module load order issue (thanks Joe! I'll review win32 within three days per Gregg's notes). But you can't veto the status quo. Today, mod_ldap and mod_authnz_ldap already must bind to the ldap provider. They are consumers of the stub functions And I'd nix your definition of mod_ldap... if it an "ldap shared cache provider" then it should have been suitably named. One can omit such a feature and still use mod_authnz_ldap. Of course, that was not possible because mod_authnz_ldap required mod_ldap required the ldap helpers required an ldap client library. > This was an observation, not part of the veto. It's important because there > are people who > are really keen to get v2.4 out the door, and this means practically is that > a suboptimal > API is being rushed unnecessarily into GA, and that is really really bad. Suboptimal? Sure. But IJFW, which has been the critera for httpd for as long as I've been here. Not acceptable at APR, but just fine, here. > The solution we agreed on in the past was to rewrite apr_ldap to fit the > pattern of > apr_dbd, but this effort was held up by a whole lot of problems in the > apr_dbd API that > were identified during review of the apr_crypto API, which was modeled on the > apr_dbd API. > This effort was also held up by the focus on getting httpd v2.4 out the door. No. We didn't agree upon a solution. We agreed upon a design pattern. But that was never implemented, ergo never solved, ergo it's vapor. > wrowe got impatient and removed apr_ldap from apr-trunk, which on the face of > it isn't a > problem for httpd because apr-trunk isn't a released entity yet, nor is it > likely to be > until the issues with apr_dbd (and as I understand apr_dbm) are fixed (among > other > issues). This move just forces us to solve the apr_ldap issue before apr v2.0 > is released. > It doesn't however put httpd under any obligation to take any drastic > measures for httpd > v2.4, because the existing apr_ldap library exists and is supported in apr > v1.x. You are absolutely right, httpd is under no obligation to support APR 2.0, or APR 1.x, or pocore, or any other library. It is an independent project. > In short, when httpd v2.4 is released, we will be free to focus our attention > on apr_ldap > and get it fixed. > > There is no need for any temporary hacks before then (where "temporary" is > defined as > "permanently baked into the httpd v2.4 API"). I have no expectation that it will be fixed, and the majority voted at APR to evict apr_ldap, therefore it is gone (not be veto or fiat, but by the preference of the majority). I have reacted accordingly because httpd would not have been happy if it had abandoned these helpers and they were not present for httpd's consumption. On the assumption that APR and httpd are now distinct, that httpd will not require httpd-deps to run, and that httpd will hopefully consume apr 1.x or apr 2.0 once it is released, this solution is correct for the short term health of httpd. httpd and apr major.minor lifespans have been measured in decades (.5 .. 1.5) and it would be foolish to ship something another project has abandoned, which was the basis of questioning if expat was the right choice going forwards. With the addition of libxml2 support it is no longer a question or risk. apr_ldap was a risk, and this change proposed to fix it. I agree with Joe's work to complete this, and it is not a veto'able change for reasons rehashed on two dev lists. Call a vote to reject providing ap_ldap in httpd 2.4, if you like. Because the technical solution is identical to the technical solution previously provided in httpd 2.2 with apr-util 1.x, there isn't a technical basis to your objection. Because you are trying to pull an end-run around the eviction of the apr_ldap API (which would go something like "apr 2.0 didn't ship with apr_ldap so I veto httpd picking up that version") there is not even merit to your veto. A few weeks ago you wanted a dozen apr-util-foo libraries. If there is someday merit to adopting a full-fledged ldap provider in APR with actual source code, and a later version of httpd decides to use that APR major.minor as a minimum version level, then things will be great and httpd/mod_[foo_]ldap will never link to an ldap client library again. But in terms of carts and horses, ldap is part of the horse, and you know which end some of us consider it.
