[Date Prev][Date Next]
Re: Providing LDIF support at the LDAP level
- Subject: Re: Providing LDIF support at the LDAP level
- From: Rich Megginson <email@example.com>
- Date: Fri, 29 Jan 2010 10:55:54 -0700
- Cc: OpenLDAP Devel <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=7Pq48JuC474Fn37H9A18wLaNSn4va2TCdHEQ7t7iTrI=; b=TdmHzwWk3TVyu1iguN62mba+tKIlBmiSeEGDRI+sp4Hoew2a+gt3XGjKnqihdaRHdi F0DJz1a64ibSLHYZXjwIBbratUccPBFnNXyDJFQ5vACizj4ROzNXxXKJWBkwtdOGepiR 8DzmItErYgIeDfKZ58Y6Lo1Y+0OmDsW2fOIIc=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jLZmDrVEovs+3hULfGefZt11iwtjtmtbkfa/LBPWFSokz/DdI4MlYFNNjP2U3wgcUQ 25oAa/JIdYDh1yReqHlbFUPflXdZr058P75+XFEcdjYLq+MOS+mrzK3v6XEFz5I+Nvlc NdwnzHnlp25RgyvW9kU6Giu/+l3UKF7osgdBk=
- In-reply-to: <4B5F7525.email@example.com>
- References: <4B577983.firstname.lastname@example.org> <4B5F5DB2.email@example.com> <4B5F7525.firstname.lastname@example.org>
- User-agent: Thunderbird 220.127.116.11 (X11/20090609)
Howard Chu wrote:
Rich Megginson wrote:
Any comments at all? Good? Bad? Don't Care?
Sorry, got busy with other things.
I have some concerns about struct ldifrecord, relatively minor though. In new
APIs I prefer to use struct bervals exclusively, no naked char *s.
(Ultimately, if we ever get to rewriting the C LDAP API, I would completely
eliminate char *s, as we already have in the server.) Also, unless you're
actually using a BerVArray, you should use actual struct bervals, not pointers
to structs. I.e., unless there's some substantial benefit to having them
separately allocatable, it's better to avoid the extra malloc of the berval
structure and just embed the thing in the main structure. This is all standard
practice for OpenLDAP code.
In ldifutil.c your main comment refers to ldap_mod_from_ldifrec() but there is
no such function in the file.
The large #if 0 block /* we should faithfully encode the LDIF... should just
be deleted, we will never use that code in the future. I left it in place as a
reminder to myself, but when migrating code from place to place we should drop
anything obsolete instead of carrying it over forever.
Thanks. Here are the new patches
Rich Megginson wrote:
This patch provides low level LDIF support in libldif and high level
support in libldap.
The libldap support is in the form of
LDAP_F( int )
const char *errstr,
unsigned int flags,
void *ctx ));
Where rbuf and linenum come from ldif_read_record; lr is new (see
below); errstr is the string prefix to print for error/debug messages
(usually the program name e.g. "ldapmodify"), flags are one of these:
#define LDIF_DEFAULT_ADD 0x01 /* if changetype missing, assume
#define LDIF_ENTRIES_ONLY 0x02 /* ignore changetypes other than add */
#define LDIF_NO_CONTROLS 0x04 /* ignore control specifications */
and ctx is the memory context (for ber_*alloc_x)
LDIFRecord returns all of the data from the LDIF record, regardless of
what type of operation it is. The lr_op field is used to determine
the type of operation, and the other fields return the operation
specific data. There is also a section of several data fields used by
the internal implementation (lifted almost verbatim from
ldapmodify.c). This is cleaned up properly by ldap_ldif_record_done()
If the LDIF record in rbuf contains no actual record (e.g. the
version: field, comments only, etc.) then the return value of
ldap_parse_ldif_record() will be 0, but the lr_op field will also be 0.