Howard Chu writes: > So, what do folks think about reviving libldif as an exported piece of the > distribution?
Exporting LDIF parsing sounds fine. Hopefully compatible with existing libldifs (mozldap libldif and maybe very-old openldap libldif), though I haven't looked at either yet. But.. I can't decide what I think about dependencies. The way OpenLDAP libs are split up in liblber and libldap is geting in the way, as usual. For an app without LDAP/networking, it can be annoying to have to drag in libldap and via that OpenSSL, SASL, which can drag in Berkeley DB, and I don't know what else, just to parse LDIF files. When they're all already installed I suppose it rarely matters much nowadays, but it may be a different story for maintaining/downloading precompiled packages. > From: h...@symas.com > rmegg...@redhat.com wrote: >> I think this could be accomplished in one of two ways: >> 1) Just have libldif return lists of struct berval* for the various data >> parsed. The caller would be responsible for turning these into LDAPMod >> or LDAPControl structures - the advantage is that libldif doesn't have >> to know about any of these higher level structures That sounds nice in making libldif almost standalone - needs only liblber. For that matter, if someone wants to get rid of that we could provide hooks for allocation and log functions. >> 2) Have libldif create LDAPMod and LDAPControl - I think this could be >> accomplished by having ldif.c #include<ldap.h> to pull in the >> definitions of LDAPMod and LDAPControl - would this be ok? Does this need libldap? Or will it be sufficient to tell the user that he should use ldap_controls_free() or functions he can copy&paste from libldap, so he can avoid libldap if he really wants to? > Let's move this discussion to the openldap-devel mailing list. I'm > thinking (2) is OK but I'd like to hear from other developers / > potential users of this library. -- Hallvard
