New LDAP C API

[simo]

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
output.
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 :)

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org