Subject: RE: Border directories

From: "David P. Kemp" <[email-masked]>
Date: Fri, 12 May 2000 11:24:14 -0400 (EDT)

Aren't you leaving out both a block and an assumption in the
HTTP path?

The assumptions are that the DSA not only is based on an RDBMS but
that the RDBMS interface is exposed to other applications.  If
these assumptions are true, the paths would be more like:

  client -> LDAP client -> LDAP server ---------\
                                                 \
                                                  RDBMS
                                                 /
  client -> HTTP GET -> Apache w/mod_perl & DBI-/

It's not obvious that an HTTP server with a DB interface can be made to
have a smaller footprint than an LDAP server with a DB interface, or
that server footprint is even a useful metric.  I'd be more concerned
with transaction response time as a function of offered load, using
identical hardware.

More importantly, the assumption that DSAs are generally based on RDBMS
backends is not obviously valid - directories and RDBMSs have different
strengths.  Implementing one as an interface to the other, though
possible, is not likely to win any performance benchmarks.  Perhaps
a few DSA vendors will chime in here with some ground truth on RDBMS
usage and API accessability to 3rd party apps.

Dave

> From: [email-masked] (Peter Gutmann)
>
> 
> "Walter Williams" <[email-masked]> writes:
> 
> >Last I checked, as the information is stored in a directory to begin with,
> 
> Last I checked all the LDAP directories I could find used either
> Berkeley DB or an RDBMS to store information.  With LDAP you have:
> 
>  client -> LDAP (client) -> LDAP (server) -> RDBMS
> 
> What I was suggesting is:
> 
>  client -> HTTP GET -> RDBMS
> 
> cutting out the superfluous LDAP bloat in the middle.
> 
> Peter.

---

From: Colin Robbins <[email-masked]>
Date: Fri, 12 May 2000 17:07:01 +0100

> usage and API accessability to 3rd party apps.

There is an assumption that because a DSA is based on a RDBMS,  you can use
RDBMS tools to access the data directly.  This is a false assumption.

Due to the mismatch between Directory requirements and a RDBMS, directory
vendors using a RDBMS generally have to write an interface layer to map data
between directory constructs and RDBMS constructs.   This generally means
the data in the RDBMS is structured to meet the directory needs, and not
other application needs.  As such, using third party RDBMS tools becomes
very difficult - the data is not is an easily-usable form.

If anyone is interested in the technical reasons why a RDBMS is bad news for
directory performance, then there is a white paper " Use of OODB Technology
for Directories" written by an independent expert on our web site
(http://www.nexor.com/info/papers.htm) that describes these problems in
detail.
NEXOR's own DSA is fundamentally not based on a RDBMS due to these problems.

If you want to access data in a Directory, then the only reliable method is
to use Directory APIs, as provided by the directory vendors.   In addition
to understanding the data structure, they also know about application
constraints.  For example access control.   Going direct to a RDBMS is
likely to bypass any application access controls provided by the Directory
vendor.

Colin