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

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

masarati@aero.polimi.it wrote:
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.

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
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?)
Ok. So libldif would then return the attr/vals, controls (other stuff?) as arrays of struct berval *.

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
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:


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.