[Date Prev][Date Next]
Re: Fwd: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
- To: Hallvard B Furuseth <email@example.com>
- Subject: Re: Fwd: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
- From: Rich Megginson <firstname.lastname@example.org>
- Date: Mon, 04 Jan 2010 14:56:30 -0700
- Cc: Howard Chu <email@example.com>, OpenLDAP Devel <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=v2iLa0pkK52hh2O3Bf3gIGpAygW3v29zvxTEsiQA4XU=; b=bSxpPVG9a0/U7pIwthvxno/SU0cRQ6EQVFIG3PRqEFQlfqW/B/NThRdoYJJHsA10II xeLrUDbxMVsDYerxbmDBmQgPwq5UVimp2SD+uzV1jnrBF4C5Jmfpbqu5GFCHtrF+0bPX g4J616K41z5rBR+YvcYMBgtFxis+PsBmO2+s0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rOUi+TEVEFZEw98VsEfz4nTFvnH9ylrKSNgffHVr2yWkr9JA7IjHGL+osMczcFMi2b raFHkchnBXpA9RYtoxeG0LTwziy1UPLcEmtSnu9CZZPEtOYjd1EuV32+zTUoJav8+rty FPkJfY8Xn096Dj5i/ShaWUJS5IWJo7Ydtlomc=
- In-reply-to: <email@example.com>
- References: <4B29F8DD.firstname.lastname@example.org> <email@example.com>
- User-agent: Thunderbird 22.214.171.124 (X11/20090609)
Hallvard B Furuseth wrote:
The original patch I proposed in
Enhancements?id=6194;selectid=6194 is roughly compatible with mozldap.
Howard Chu writes:
So, what do folks think about reviving libldif as an exported piece of the
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.
I would prefer this approach - it would be most convenient to have the
LDIF parsed into LDAPMod and LDAPControl structures - for those (very
few?) apps that will want to use libldif standalone, it's easy to free
LDAPMod and LDAPControl structure data.
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.
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.