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: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz (Peter Gutmann)
"Walter Williams" <walter(_dot_)williams(_at_)genuity(_dot_)com> 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.