New LDAP C API
idra at samba.org
Wed Feb 14 01:53:26 GMT 2007
On Tue, 2007-02-13 at 17:06 -0800, Howard Chu wrote:
> Love Hörnquist Åstrand wrote:
> > I really don't like the name of "struct bervals".
> The struct name and the BerValue typedef have been around forever. I
> don't think this is any worse than krb5_data, but would be happy to hear
> alternatives. As for data that "in practice always is strings" - that's
> the sort of approach that created a big part of the mess in LDAP in the
> first place, thinking that everything is just strings. When "always"
> turns out to be just 80-90% of the time, you're left with a real pain
> that remaining portion of time.
howard, reread what Love said, he distinguishes between input and
I think he means that what he likes is to have the chance to provide
input data alternatively as a char * _or_ as a berval struct (I hate the
name as well, of course samba's data_blob is much better <g>).
> > "5. "proper" error handling"
> > You should seriously consider using something like the heimdal
> > krb5_get_error_string
> > api to get out sane error messages (but with added error code).
> Good idea. Error handling in libldap has always been weak.
> > I don't see malloc happy as a big problem.
> Most people don't, they've been trained to believe that malloc is ok.
> But in the optimization work that went on between OpenLDAP 2.0 and 2.1
> we found that 50% of our CPU time was in libc, 30% malloc() related and
> 20% strlen(). One major reason that slapd in 2.1 benchmarks 200 times
> faster than slapd in 2.0 is because we eliminated most of those calls.
> Using BerVals everywhere was also a part of that.
> It's true that using a better malloc library can help (see my malloc
> benchmark results http://www.highlandsun.com/hyc/malloc/ ) but it's
> better not to use it at all if it can be avoided.
just do not overreact :)
Samba Team GPL Compliance Officer
email: idra at samba.org
More information about the samba-technical