Howard Chu hyc at
Wed Feb 14 01:06:49 GMT 2007

Love Hörnquist Åstrand wrote:
>> I've already invited folks from the Fedora Directory Server team to 
>> participate in this new design, and I'd like to get input from you 
>> folks too. Anybody who's done a significant amount of work with LDAP 
>> has probably cursed the API more than a few times. Let's fix it.
> I don't like "4. char *'s should be avoided, use struct bervals more 
> extensively"
> if it means removing char * that in practice always is strings. I 
> don't mind
> getting output data in struct { void *, size_t ); elements, its when 
> its input
> it sucks that you have wrapp everything in a struct foo just to pass 
> it it.
> 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.
> "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 ) but it's 
better not to use it at all if it can be avoided.

  -- Howard Chu
  Chief Architect, Symas Corp.
  Director, Highland Sun
  Chief Architect, OpenLDAP

More information about the samba-technical mailing list