OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Development/6194
Full headers

From: rmeggins@redhat.com
Subject: Patch - Enhancement - provide LDIF support as libldif
Compose comment
Download message
State:
0 replies:
17 followups: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Major security issue: yes  no

Notes:

Notification:


Date: Thu, 02 Jul 2009 20:01:38 +0000
From: rmeggins@redhat.com
To: openldap-its@OpenLDAP.org
Subject: Patch - Enhancement - provide LDIF support as libldif
Full_Name: Rich Megginson
Version: CVS HEAD (2.4.16+)
OS: Fedora
URL: ftp://ftp.openldap.org/incoming/openldap-2.4.16-libldif-20090702.patch
Submission from: (NULL) (76.113.59.19)


This patch allows liblutil to provide the LDIF reading and writing functions as
public APIs in a libldif, and exposes ldif.h to the public API.

    This patch file is derived from OpenLDAP Software. All of the 
modifications to OpenLDAP Software represented in the following 
patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not 
assigned rights and/or interest in this work to any party. I, Richard 
Megginson am authorized by Red Hat, Inc., my employer, to release this 
work under the following terms.

    Red Hat, Inc. hereby place the following modifications to OpenLDAP 
Software (and only these modifications) into the public domain. Hence, 
these modifications may be freely used and/or redistributed for any 
purpose with or without attribution and/or other notice.

Followup 1

Download message
Date: Tue, 07 Jul 2009 16:12:15 -0700
From: Howard Chu <hyc@symas.com>
To: rmeggins@redhat.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
rmeggins@redhat.com wrote:
> Full_Name: Rich Megginson
> Version: CVS HEAD (2.4.16+)
> OS: Fedora
> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.16-libldif-20090702.patch
> Submission from: (NULL) (76.113.59.19)
>
>
> This patch allows liblutil to provide the LDIF reading and writing
functions as
> public APIs in a libldif, and exposes ldif.h to the public API.

See also ITS#4033; ldif.h only parses LDIF into chunks/records, it's still up 
to the caller to turn these records into something meaningful. In fact libldif 
used to be a library of its own, but in RE22 we made the decision to merge it 
into liblutil because its functionality is so limited. I don't expect we'll 
reverse this decision unless/until it gets enough parsing added to it to make 
it more generally useful.

>      This patch file is derived from OpenLDAP Software. All of the
> modifications to OpenLDAP Software represented in the following
> patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not
> assigned rights and/or interest in this work to any party. I, Richard
> Megginson am authorized by Red Hat, Inc., my employer, to release this
> work under the following terms.
>
>      Red Hat, Inc. hereby place the following modifications to OpenLDAP
> Software (and only these modifications) into the public domain. Hence,
> these modifications may be freely used and/or redistributed for any
> purpose with or without attribution and/or other notice.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 2

Download message
Date: Tue, 07 Jul 2009 17:48:59 -0600
From: Rich Megginson <rmeggins@redhat.com>
To: Howard Chu <hyc@symas.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
Howard Chu wrote:
> rmeggins@redhat.com wrote:
>> Full_Name: Rich Megginson
>> Version: CVS HEAD (2.4.16+)
>> OS: Fedora
>> URL: 
>> ftp://ftp.openldap.org/incoming/openldap-2.4.16-libldif-20090702.patch
>> Submission from: (NULL) (76.113.59.19)
>>
>>
>> This patch allows liblutil to provide the LDIF reading and writing 
>> functions as
>> public APIs in a libldif, and exposes ldif.h to the public API.
>
> See also ITS#4033; ldif.h only parses LDIF into chunks/records, it's 
> still up to the caller to turn these records into something 
> meaningful. In fact libldif used to be a library of its own, but in 
> RE22 we made the decision to merge it into liblutil because its 
> functionality is so limited. I don't expect we'll reverse this 
> decision unless/until it gets enough parsing added to it to make it 
> more generally useful.
I think it's very useful as it is - the mozldap libldif (which is almost 
identical in functionality to my proposed openldap libldif) is used in 
several different applications in the 389 directory server suite.  What 
more does it need?  Some sort of higher level "entry" and "attribute" 
abstraction?
>
>>      This patch file is derived from OpenLDAP Software. All of the
>> modifications to OpenLDAP Software represented in the following
>> patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not
>> assigned rights and/or interest in this work to any party. I, Richard
>> Megginson am authorized by Red Hat, Inc., my employer, to release this
>> work under the following terms.
>>
>>      Red Hat, Inc. hereby place the following modifications to OpenLDAP
>> Software (and only these modifications) into the public domain. Hence,
>> these modifications may be freely used and/or redistributed for any
>> purpose with or without attribution and/or other notice.
>



Followup 3

Download message
Date: Tue, 18 Aug 2009 09:34:39 -0600
From: Rich Megginson <rmeggins@redhat.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
Any ideas about what it would take to make a public LDIF API?



Followup 4

Download message
Date: Tue, 18 Aug 2009 11:17:49 -0600
From: Rich Megginson <rmeggins@redhat.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
This is a cryptographically signed message in MIME format.

--------------ms040103040408070506080709
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

One thing that a general purpose LDIF parser needs is support for change 
records - for example, the ability to read in a changetype: modify and 
parse the changes into an LDAPMod ** or something like that.  There's 
already code in ldapmodify to do this, it would need to be refactored 
into libldif.

Since the library should be able to parse any sort of LDIF, the parse 
function would have to read in the first couple of lines of each LDIF 
record to determine if it is a plain entry or a change record.  The 
parser would return a struct with a union for the different sets of 
parameters.  The function that parses the LDIF could take a flag (or 
bitmask) that specifies which types of records it expects (e.g. the LDIF 
parser usage in slapadd would want to ignore/error on change records).

--------------ms040103040408070506080709
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC
AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX
DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG
CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy
ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv
boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7
l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C
MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA
AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G
CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3
2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ
02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F
afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc
VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs
IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF
MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn
Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov
oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg
VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi
F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR
eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+
dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV
gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA
NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R
aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65
Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR
MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv
d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u
IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy
ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO
ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va
qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6
MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB
LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl
bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh
uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO
jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C
AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd
RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH
ATAcBgkqhkiG9w0BCQUxDxcNMDkwODE4MTcxNzQ5WjAjBgkqhkiG9w0BCQQxFgQUzzoGkS1H
KNU2s4j2AyhGil+I2/kwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg
Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD

Message of length 5686 truncated


Followup 5

Download message
Date: Tue, 18 Aug 2009 21:20:25 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: rmeggins@redhat.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
rmeggins@redhat.com wrote:
> One thing that a general purpose LDIF parser needs is support for change 
> records - for example, the ability to read in a changetype: modify and 
> parse the changes into an LDAPMod ** or something like that.  There's 
> already code in ldapmodify to do this, it would need to be refactored 
> into libldif.

There are not only add/modify operations possible in a LDIF file.

Personally I'm banging my head about adding full support for change records in
python-ldap's LDIF parser. At the end one would have to trigger all LDAP
operations including processing of LDAPv3 extended controls. So I guess for a
C API this would mean a call-back interface full-featured like libldap itself.
(So the next question would be whether to stick with this LDAP C API...)

Ciao, Michael.



Followup 6

Download message
Date: Wed, 16 Dec 2009 11:05:20 -0700
From: Rich Megginson <rmeggins@redhat.com>
To: openldap-its@OpenLDAP.org
CC: rmeggins@redhat.com
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
The ldif code does not currently have knowledge of any of the higher 
level LDAP data types such as LDAPMod or LDAPControl - some of the 
proposals would have the ldif API return these objects - Do we really 
want to introduce this higher level knowledge into the relatively low 
level libldif, along with the dependency on libldap?  I think in order 
to do this properly, we would have to introduce a new LDAP API e.g. 
ldap_mods_from_ldif(const char *ldifstr, LDAPMod***, LDAPControl***) or 
something like that - something that would parse the given ldif record 
into those higher level data types.



Followup 7

Download message
Date: Wed, 16 Dec 2009 20:33:14 -0700
From: Rich Megginson <rmeggins@redhat.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
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 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?



Followup 8

Download message
Date: Wed, 16 Dec 2009 19:45:55 -0800
From: Howard Chu <hyc@symas.com>
To: rmeggins@redhat.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
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 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
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 9

Download message
Date: Tue, 22 Dec 2009 19:43:39 -0800
From: Howard Chu <hyc@symas.com>
To: rmeggins@redhat.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
rmeggins@redhat.com wrote:
> The ldif code does not currently have knowledge of any of the higher
> level LDAP data types such as LDAPMod or LDAPControl - some of the
> proposals would have the ldif API return these objects - Do we really
> want to introduce this higher level knowledge into the relatively low
> level libldif, along with the dependency on libldap?  I think in order
> to do this properly, we would have to introduce a new LDAP API e.g.
> ldap_mods_from_ldif(const char *ldifstr, LDAPMod***, LDAPControl***) or
> something like that - something that would parse the given ldif record
> into those higher level data types.

Should have mentioned this sooner; this ITS needs to be merged with ITS#4033.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 10

Download message
Date: Fri, 09 Apr 2010 12:01:40 -0600
From: Rich Megginson <rmeggins@redhat.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
Full_Name: Rich Megginson
Version: CVS HEAD (2.4.21+)
OS: Fedora
URL: 
ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api-20100409.patch

This patch allows liblutil to provide the LDIF reading and writing 
functions as
public APIs in a libldif, and exposes ldif.h to the public API.  This 
patch also creates
a new LDAP API for parsing raw LDIF records into higher level LDAP 
structures
such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes
ldapmodify.c to use the new API.

    This patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following
patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not
assigned rights and/or interest in this work to any party. I, Richard
Megginson am authorized by Red Hat, Inc., my employer, to release this
work under the following terms.

    Red Hat, Inc. hereby place the following modifications to OpenLDAP
Software (and only these modifications) into the public domain. Hence,
these modifications may be freely used and/or redistributed for any
purpose with or without attribution and/or other notice.



Followup 11

Download message
Date: Fri, 9 Apr 2010 20:15:49 +0200 (CEST)
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as 
     libldif
From: masarati@aero.polimi.it
To: rmeggins@redhat.com
Cc: openldap-its@openldap.org
> Full_Name: Rich Megginson
> Version: CVS HEAD (2.4.21+)
> OS: Fedora
> URL:
> ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api-20100409.patch
>
> This patch allows liblutil to provide the LDIF reading and writing
> functions as
> public APIs in a libldif, and exposes ldif.h to the public API.  This
> patch also creates
> a new LDAP API for parsing raw LDIF records into higher level LDAP
> structures
> such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes
> ldapmodify.c to use the new API.
>
>     This patch file is derived from OpenLDAP Software. All of the
> modifications to OpenLDAP Software represented in the following
> patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not
> assigned rights and/or interest in this work to any party. I, Richard
> Megginson am authorized by Red Hat, Inc., my employer, to release this
> work under the following terms.
>
>     Red Hat, Inc. hereby place the following modifications to OpenLDAP
> Software (and only these modifications) into the public domain. Hence,
> these modifications may be freely used and/or redistributed for any
> purpose with or without attribution and/or other notice.

Kurt,

if you give IPR clearance I can start (evaluating and) integrating this.

p.



Followup 12

Download message
Date: Sun, 11 Apr 2010 18:06:55 +0200 (CEST)
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as 
     libldif
From: masarati@aero.polimi.it
To: rmeggins@redhat.com
Cc: openldap-its@openldap.org
> Full_Name: Rich Megginson
> Version: CVS HEAD (2.4.21+)
> OS: Fedora
> URL:
> ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api-20100409.patch

Rich,

ldifutil.c seems to be missing in that file.  Can you provide it?  Either
a separate file, or a new version of the patch is fine.

Thanks, p.


> This patch allows liblutil to provide the LDIF reading and writing
> functions as
> public APIs in a libldif, and exposes ldif.h to the public API.  This
> patch also creates
> a new LDAP API for parsing raw LDIF records into higher level LDAP
> structures
> such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes
> ldapmodify.c to use the new API.
>
>     This patch file is derived from OpenLDAP Software. All of the
> modifications to OpenLDAP Software represented in the following
> patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not
> assigned rights and/or interest in this work to any party. I, Richard
> Megginson am authorized by Red Hat, Inc., my employer, to release this
> work under the following terms.
>
>     Red Hat, Inc. hereby place the following modifications to OpenLDAP
> Software (and only these modifications) into the public domain. Hence,
> these modifications may be freely used and/or redistributed for any
> purpose with or without attribution and/or other notice.
>
>
>
>
>




Followup 13

Download message
Date: Sun, 11 Apr 2010 14:16:44 -0600
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
From: Rich Megginson <richm@stanfordalumni.org>
To: openldap-its@openldap.org
Cc: masarati@aero.polimi.it
On Sun, Apr 11, 2010 at 10:07 AM,  <masarati@aero.polimi.it> wrote:
>> Full_Name: Rich Megginson
>> Version: CVS HEAD (2.4.21+)
>> OS: Fedora
>> URL:
>> ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api=
-20100409.patch
>
> Rich,
>
> ldifutil.c seems to be missing in that file. =A0Can you provide it? =A0Ei=
ther
> a separate file, or a new version of the patch is fine.

Sorry about that.  You can find it here:
http://rmeggins.fedorapeople.org/ldifutil.c

>
> Thanks, p.
>
>
>> This patch allows liblutil to provide the LDIF reading and writing
>> functions as
>> public APIs in a libldif, and exposes ldif.h to the public API. =A0This
>> patch also creates
>> a new LDAP API for parsing raw LDIF records into higher level LDAP
>> structures
>> such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and
changes
>> ldapmodify.c to use the new API.
>>
>> =A0 =A0 This patch file is derived from OpenLDAP Software. All of the
>> modifications to OpenLDAP Software represented in the following
>> patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not
>> assigned rights and/or interest in this work to any party. I, Richard
>> Megginson am authorized by Red Hat, Inc., my employer, to release this
>> work under the following terms.
>>
>> =A0 =A0 Red Hat, Inc. hereby place the following modifications to
OpenLD=
AP
>> Software (and only these modifications) into the public domain. Hence,
>> these modifications may be freely used and/or redistributed for any
>> purpose with or without attribution and/or other notice.
>>
>>
>>
>>
>>
>
>
>
>
>
>
>



Followup 14

Download message
Date: Sun, 11 Apr 2010 23:29:24 +0200 (CEST)
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as 
     libldif
From: masarati@aero.polimi.it
To: "Rich Megginson" <richm@stanfordalumni.org>
Cc: openldap-its@openldap.org
> Sorry about that.  You can find it here:
> http://rmeggins.fedorapeople.org/ldifutil.c

Gotit, thanks.  I have one first comment: the public API does not
generally expose the memory context.  I'm renaming
ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating
the void *ctx arg from ldap_parse_ldif_record(), if you don't mind.

p.



Followup 15

Download message
Date: Mon, 12 Apr 2010 02:13:48 +0200 (CEST)
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as 
     libldif
From: masarati@aero.polimi.it
To: richm@stanfordalumni.org
Cc: openldap-its@openldap.org
>
>> Sorry about that.  You can find it here:
>> http://rmeggins.fedorapeople.org/ldifutil.c
>
> Gotit, thanks.  I have one first comment: the public API does not
> generally expose the memory context.  I'm renaming
> ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating
> the void *ctx arg from ldap_parse_ldif_record(), if you don't mind.

tested and applied to HEAD; please test.  Thanks, p.



Followup 16

Download message
Date: Mon, 12 Apr 2010 02:52:49 +0200 (CEST)
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as 
     libldif
From: masarati@aero.polimi.it
To: richm@stanfordalumni.org
Cc: openldap-its@openldap.org
>>
>>> Sorry about that.  You can find it here:
>>> http://rmeggins.fedorapeople.org/ldifutil.c
>>
>> Gotit, thanks.  I have one first comment: the public API does not
>> generally expose the memory context.  I'm renaming
>> ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating
>> the void *ctx arg from ldap_parse_ldif_record(), if you don't mind.
>
> tested and applied to HEAD; please test.  Thanks, p.

More comments:

1) perhaps it may be worth providing a function that converts a LDIFRecord
structure into a string, and one that sends it to a stream

2) I note you put

        LDAPMod **lr_mods; /* list of mods for LDAP_REQ_MODIFY,
LDAP_REQ_ADD */
        struct berval lr_newrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN,
LDAP_REQ_RENAME */
        struct berval lr_newsuperior; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN,
LDAP_REQ_RENAME */
        int lr_deleteoldrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN,
LDAP_REQ_RENAME */
        /* the following are for future support */
        struct berval lr_extop_oid; /* LDAP_REQ_EXTENDED */
        struct berval lr_extop_data; /* LDAP_REQ_EXTENDED */
        struct berval lr_cmp_attr; /* LDAP_REQ_COMPARE */
        struct berval lr_cmp_bvalue; /* LDAP_REQ_COMPARE */

in the structure; the last four are not used right now.  I think it would
make sense to group struct members by op in substructures, and then put
them in a union, to stress the fact that they're mutually exclusive.  Much
like Howard did for the corresponding substructures in the Operation
struct in slapd.

p.



Followup 17

Download message
Date: Mon, 12 Apr 2010 16:19:49 -0600
From: Rich Megginson <rich.megginson@gmail.com>
To: masarati@aero.polimi.it
CC: openldap-its@openldap.org
Subject: Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
masarati@aero.polimi.it wrote:
>>>> Sorry about that.  You can find it here:
>>>> http://rmeggins.fedorapeople.org/ldifutil.c
>>>>         
>>> Gotit, thanks.  I have one first comment: the public API does not
>>> generally expose the memory context.  I'm renaming
>>> ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and
eliminating
>>> the void *ctx arg from ldap_parse_ldif_record(), if you don't mind.
>>>       
>> tested and applied to HEAD; please test.  Thanks, p.
>>     
>
> More comments:
>
> 1) perhaps it may be worth providing a function that converts a LDIFRecord
> structure into a string, and one that sends it to a stream
>   
For debugging purposes, or something like that?
> 2) I note you put
>
>         LDAPMod **lr_mods; /* list of mods for LDAP_REQ_MODIFY,
> LDAP_REQ_ADD */
>         struct berval lr_newrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN,
> LDAP_REQ_RENAME */
>         struct berval lr_newsuperior; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN,
> LDAP_REQ_RENAME */
>         int lr_deleteoldrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN,
> LDAP_REQ_RENAME */
>         /* the following are for future support */
>         struct berval lr_extop_oid; /* LDAP_REQ_EXTENDED */
>         struct berval lr_extop_data; /* LDAP_REQ_EXTENDED */
>         struct berval lr_cmp_attr; /* LDAP_REQ_COMPARE */
>         struct berval lr_cmp_bvalue; /* LDAP_REQ_COMPARE */
>
> in the structure; the last four are not used right now.  I think it would
> make sense to group struct members by op in substructures, and then put
> them in a union, to stress the fact that they're mutually exclusive.  Much
> like Howard did for the corresponding substructures in the Operation
> struct in slapd.
>   
Please check out this patch - 
ftp://ftp.openldap.org/incoming/openldap-2.4.21-ldifrecord-union-20100412.patch
> p.
>
>
>
>
>   


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org