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