Joe Orton wrote:
This describes the way the DBD/DSO code works now. This type of arrangement is perfect for code which has vtable-like abstractions on top of the third-party library, as DBD does, but doesn't really work for anything else.
yes - requires abstraction but doesn't necessarily mean multiple backends, if they serve no purpose (one ldap provider should be plenty). On one machine you might have netscape, openldap or others, so this makes life much easier; let's say you have another component that will do openldap, you just swap for openldap as the provider and avoid the usual symbol clashes.
For e.g. the LDAP code this is simply not realistic at all without completely rewriting the code to provide a real abstraction; currently the LDAP code *requires* a dependency between application and the ABI of the underlying LDAP toolkit - i.e. direct library linkage.
And you just mentioned in your top-post that this is 2.0, let the breakage of our API begin :) Bill
