Full_Name: Pierangelo Masarati Version: any OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando There are quite a few local functions with no namespace (e.g. re_encode_request()), but what seems to be mostly incorrect is ldap namespace pollution (e.g. ldap_chase_v3referrals()). Finally, there are quite a few occurrences of ldap_int_tls_config() used outside libldap (in slapd). Since all those functions are not meant to be exposed, I guess fixing the (mis)use of the ldap namespace should not create issues. p.
moved from Incoming to Development
ando@sys-net.it writes: > Since all those functions are not meant to be exposed, I guess fixing > the (mis)use of the ldap namespace should not create issues. Wait for 2.5 to break binary compatibility. If a function is there and is useful, people will dig it out and use it. Just like back-bdb used (uses?) some internal Berkeley DB locking function. -- Hallvard
h.b.furuseth@usit.uio.no wrote: > ando@sys-net.it writes: >> Since all those functions are not meant to be exposed, I guess fixing >> the (mis)use of the ldap namespace should not create issues. > > Wait for 2.5 to break binary compatibility. Sure, no hurry. I'm just getting a bit confused when digging into very nested libldap stuff... > If a function is there and > is useful, people will dig it out and use it. That's probably my last concern, though :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
h.b.furuseth@usit.uio.no wrote: > ando@sys-net.it writes: >> Since all those functions are not meant to be exposed, I guess fixing >> the (mis)use of the ldap namespace should not create issues. > Wait for 2.5 to break binary compatibility. If a function is there and > is useful, people will dig it out and use it. Agreed. But we can probably fix slapd's use of ldap_int APIs. > Just like back-bdb used > (uses?) some internal Berkeley DB locking function. (Not any more...) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes
s/ldap_int_tls_config/ldap_pvt_tls_config/ in HEAD wait for 2.5?
None of this applies to libldap(_r)/liblber in master anymore. Nor does slapd seem to reference ldap_int_* symbols directly.