1:38 a.m.
Hallvard B Furuseth wrote:
> 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.
The original patch I proposed in
http://www.openldap.org/its/index.cgi/Software
Enhancements?id=6194;selectid=6194 is roughly compatible with mozldap.
> 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(a)symas.com
>> rmeggins(a)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?
>
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 think we could split the problem in two:
1) low-level parsing into arrays of bervals (in libldif?)
2) higher-level parsing in LDAP* structures (belongs to libldap, since
needs at least the declaration of those structures). This level would
delegate parsing to libldif, and simply deal with arranging data into
LDAP* structures.
I understand this approach would probably be in constrast with Rich's need
of parsing into LDAP* structs from within libldif, and in any case to
avoid the need to link libldap... The only alternative I see is to have
libldif include ldap.h and act as a standalone library.
All in all, libldap does not need to depend on libldif for turning LDIF
into LDAP* structs (a client would). So libldap may need libldif for
low-level dealing with LDIF data - but note:
./libraries/liblutil/fetch.c
./libraries/liblutil/ldif.c
./servers/slapd/slapadd.c
./servers/slapd/slapcommon.c
./servers/slapd/bconfig.c
./servers/slapd/back-sql/config.c
./servers/slapd/x.diff
./servers/slapd/overlays/auditlog.c
./servers/slapd/overlays/retcode.c
./servers/slapd/root_dse.c
./servers/slapd/back-ldif/ldif.c
./servers/slapd/back-ldap/config.c
./servers/slapd/controls.c
./servers/slapd/back-monitor/log.c
./servers/slapd/entry.c
./servers/slapd/main.c
./clients/tools/ldapexop.c
./clients/tools/common.c.orig
./clients/tools/ldapsearch.c.orig
./clients/tools/ldapmodify.c
./clients/tools/common.c
./clients/tools/ldapsearch.c
./include/ldif.h
currently it doesn't; only clients call ldif_* functions. So deciding
that libldif depends on libldap, and not vice versa, would be compatible
with current arrangement.
>
>> 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.
>>
p.