"David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil> writes:
(Phew, back to technical discussions at last)...
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-/
Why would you need to run Apache? The model I was using was:
client -> socket read -> server stub -> RDBMS
Every RDBMS vendor on the planet either has or is making their database
web-aware (although for security purposes I'd prefer to stick my own stub in
front of it because I don't trust anyone to get things like this right :-).
The interface is incredibly trivial, using a speed-optimised database like
MySQL (which doesn't have a "lightweight" client like, say, Oracle), the
server stub isn't more than a page or two of code (bind to a socket, read
requests, drop them into a line of SQL, then call mysql_query() and
mysql_use_result()/fetch_row() and send the result back to the caller. I'm
sure I could crank it out in a hour or so (although MySQL does have web glue
built in if you want to go that way and use the native capabilities).
Total extra overhead in the client (assuming it already speaks SMTP, which
one can probably assume for a mail client): One read and one write call.
Total overhead in the server: An accept(), a read, the aforementioned RDBMS
glue code, and a write for the results.
You can even use the standard dictionary definition of lightweight to desribe
that. It makes for a very nice, simple "gimme a cert" protocol without the
bloat and overhead of other alternatives.
Peter.