[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Fwd: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif



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: hyc@symas.com
> rmeggins@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