So, what do folks think about reviving libldif as an exported piece of the distribution?
-------- Original Message -------- Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif Date: Thu, 17 Dec 2009 03:46:08 GMT From: hyc@symas.com To: openldap-its@openldap.org
rmeggins@redhat.com wrote:
I think this could be accomplished in one of two ways:
- 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 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?
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.
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:
- 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.
- 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 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@symas.com rmeggins@redhat.com wrote:
I think this could be accomplished in one of two ways:
- 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.
- 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.
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 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@symas.com rmeggins@redhat.com wrote:
I think this could be accomplished in one of two ways:
- 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.
- 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.
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 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@symas.com rmeggins@redhat.com wrote:
I think this could be accomplished in one of two ways:
- 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.
- 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:
- 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**.
- 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.
-
Hallvard B Furuseth -
Howard Chu -
masaratiļ¼ aero.polimi.it -
Rich Megginson