[Date Prev][Date Next]
Re: Fwd: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
Ok. So libldif would then return the attr/vals, controls (other stuff?)
as arrays of struct berval *.
Hallvard B Furuseth wrote:
Howard Chu writes:
So, what do folks think about reviving libldif as an exported piece of
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
Enhancements?id=6194;selectid=6194 is roughly compatible with mozldap.
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
parsed. The caller would be responsible for turning these into
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?)
What about the changetype field and the mod type? Should libldif just
return the strings, and let the new, higher level libldap function use
this to convert the string+values into LDAPMod*'s? Or should libldif
attempt to parse (and validate) the changetype?
I think the former - it would still be the responsibility of the client
to either know about changetypes, or use the higher level libldap function.
libldif would have a function that would take a record from an LDIF
encoded file and return
char *changetype - changetype from record (or NULL if just an entry)
char **mod_op - array of mod_ops in order
char **mod_type - array of mod_types in order
struct berval ***mod_bvals - array of values for each corresponding mod_type
and similar lists for returning the controls associated with each
record. This seems awkward - too many function arguments.
libldap would have a function to convert these arguments to an LDAPMod**
and an LDAPControl**.
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
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:
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.