Re: [ldapext] [Fwd: LDAP C API gripes]

[Michael B Allen <mba2000@ioplex.com>]

On Wed, 21 Feb 2007 11:11:17 -0500
simo <idra@samba.org> wrote:

> On Wed, 2007-02-21 at 08:01 -0800, Howard Chu wrote:
> > simo wrote:
> > > On Wed, 2007-02-21 at 07:47 -0800, Howard Chu wrote:
> > >   
> > >> Something else that comes to mind - the client library ought to be 
> > >> schema-aware. This is something that was always a given in X.500 
> > >> clients, but has never had any priority in LDAP clients. It might be 
> > >> worthwhile to implement syntax validation in the library, to catch bogus 
> > >> inputs before talking to any servers...
> > >>     
> > >
> > > Does it mean making the client retrieve the schema from the server each
> > > time? Might work on long lived apps, but an ldapadd would terribly
> > > suffer ...
> > >   
> > 
> > This would only be part of a higher level API. I would only expect GUI 
> > tools to use it, although if you're ldapadding a 512MB LDIF it might be 
> > worthwhile to use it on the commandline too.
> 
> Still the idea does not really appeal me, can you summarize very quickly
> what advantage do you get in doing that?

We just did an LDAP abstraction API that has "schema awareness". We're
doing a PHP extension and we wanted to make things "as simple as possible
but not simpler" for the sake of developers.

One of the main issues was converting strings from UTF-8 to the locale
encoding. If you don't know what attributes are strings you cannot
convert them automatically. You would have to some kind of 'get_string'
accessor function or just require the developer to either run their
web server in the UTF-8 locale or convert strings manually somehow. We
wanted to simply return a PHP array with all of the elements properly
typed. Not just strings but integers as integers and large integers as
double and boolean as 1 or 0, etc.

Another issue, as Howard mentions, are GUI tools that work with arbitrary
attributes. The classic example is trying to determine which values are
binary so that you don't print garbage at the user. IIRC ldapsearch does
this by looking at the value and trying to determine if it contains only
ascii characters. If it does not, then it base64 encodes it first.

As for retrieving the schema from the server at runtime, we did not do
that. Not just for performance reasons but more so because there is no
standard way to retrieve that information, it is awkward to do so or
you cannot do it at all (e.g. RootDSE attributes in AD have no schema
definitions).

Instead, we attack the problem at three levels:

1) By default all attribute definitions are multivalued binary. This
provides full comapibility with the current API.

2) Very common attributes are hardcoded into the library. Types
are string, boolean, binary, time, int32, and int64 with flags for
single-valued, case-exact and dn. We have a script that can query AD and
produce C declarations for all attributes on a set of DNs. Currently we
hard code about 150 attributes.

3) We allow the user to set attribute definitions at runtime using a
'plexcel_set_attrdef' function. These defs are associated with the
current context object and are released with it.

We think this strategy is quite reasonable in terms of performance and
complexity. It is backwards compatible by default. Someone has to have
"attribute intelligence". It can either be the developer or the API. In
the later case the developer can put that "attribute intellegence"
into a list of set_attrdef calls somewhere and not have to think about
it all the time.

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext