db-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robb Penoyer <rpeno...@timgia.com>
Subject [Apache Incubator Directory Proposal] From the incubator list
Date Thu, 11 Sep 2003 19:29:02 GMT

Forgive the cutting and pasting of the mail notes below - but that is the 
background. I really wanted to respond to Brian, and since Alex mentioned 
my name.

LDAPd is a java implementation of and v3 compliant LDAP server, and 
hopefulyl will soon enter the Apache Incubator as the/part of the Apache 
Directory candidate.

In the classical sense, LDAP really isn't a database, but it needs one to 
work - like everything else in the world. the primary difference is 
transactions, it doesn't have any, nor do the standard require them. To 
make LDAP work efficiently, a high performance on read operations becomes 
the focus.

LDAP and databases (relation, oo or other) do have several factors in common,
    - client and server side providers
    - system organizational areas, system tablespaces, system backends, 
schema management, security, authentication...

Where LDAP has a edge is in the somewhat static "lookup" space. Being 
optimized for read operations, handling id to value management falls into 
it's sweet spot. A well designed relational DB is much more suited for the 
transactional type data.

Can LDAP and transactional database technology leverage each other - 
absolutely. The architectural overlap is fairly astounding, and has bee the 
topic of many discussions in the LDAPd community. Consider a highly tuned 
LDAP server responsible for database schema administration (normally static 

Advantages: LDAP protocol requires replication and the ability forward 
requests, which are not available locally, to a location which can serve 
them. So the ability to manage distributed databases becomes a natural 
component. With more thought put in place, there really is no reason that 
with LDAP serving as the system engine for a database, you couldn't have 
storage managers optimized for object persistence (oodb), transaction data 
(rdbms), and hierachical information (hierarchical db) all acting as one 
database system.

I could go on for a very long time .....

From: Brian McCallister <brianm@apache.org>
To: general@incubator.apache.org
X-Mailer: Apple Mail (2.552)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

I wasn't so much looking for projects to put under the DB wing, but 
thinking of people who might be interested in LDAPd. An LDAP most 
definately is *not* an RDBMS, but it is a protocol for accessing 
hierarchical databases. After filesystems and DNS, ldap's are probably the 
most widely used hierarchical databases around.

I for one would be more than happy to contribute LDAPd, particularly if 
said alternative is Java embedable.

So, if it comes to a vote and I am allowed to vote, it has my +1.


On Thursday, September 11, 2003, at 02:26 PM, Noel J. Bergman wrote:

>>you might also want to say something about this on
>>general@db.apache.org as an LDAP is sort of a db =)
>>A high-profile new project could help liven up DB some ;-)
>I think that naming and directory services are sufficiently different from
>DB might want to consider adopting Jakarta Commons DBCP.  That topic has
>come up before, and didn't lack support.
>There are some other candidates that the DB PMC could look into incubating
>and adopting.  For example, http://axion.tigris.org/ is a rather obvious
>candidate, especially considering the committer list (geir jvanzyl mpoeschl
>Firebird would be nice, but they seem more interested in selling memberships
>in their foundation, which is completely incompatible with the ASF
>There there are ODBMS such as Ozone (wrong license, though).

From: <aok123@bellsouth.net>
To: <general@incubator.apache.org>
CC: <general@db.apache.org>, <rpenoyer@timgia.com>,
Subject: Re: Re: Official Apache Directory Project Proposal Submission
Date: Thu, 11 Sep 2003 14:24:29 -0400
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


Actually we have implemented a rudimentary relational database (non-sql)
inside the server specifically to optimize for LDAP, however the engine core
could be reused for an RDBMS.  Both and RDBMS and an LDAP server are databases

Actually the combination of an RDBMS coupled with an LDAP server would be very
powerful together.  If the data dictionary of an RDBMS is stored in LDAP the
schema remains consistant across RDBMS instances and can be managed centrally
and replicated easily.  Also works nicely for the storage of simple LUT based
contraint tables.  You know the ones u use for an enumeration of options to
constrain a column.  For example a LOAN table may have a TYPE column and there
may be a LOAN_TYPES lookup table to constrain the column containing a single
pk column of loan type varchars like so:

30 Year Fixed
15 Year Fixed
5 Year ARM

etc ...

LDAP would be great for storing LUT's where the reads are many and the writes
are few.  It's not a core table for transactions like the LOAN table itself.
This way several databases can leverage the same LUT data consistantly.  Also
you can use delegation in LDAP to let the designated authority manage the
additions to the LOAN_TYPES table.

Another member on the LDAPd team named Robb which is CC'ed in this email has
been discussing the potential for a common database library.  The library
would have a storage managment layer, a index and a search engine with an
optimizer for use in any database paradigm.

Robb's an ex Oracle developer that helped design what is to be the system
catalog for LDAPd.  He's valuable to us from a db engineering standpoint.  I'm
sure he could play a pivitol role in working with the db folks.  But please
don't take him from us just yet ;-).


 > From: Brian McCallister <mccallister@forthillcompany.com>
 > Date: 2003/09/11 Thu PM 12:27:01 EDT
 > To: general@incubator.apache.org
 > Subject: Re: Official Apache Directory Project Proposal Submission
 > Am writing up a post, but you might also want to say something about
 > this on general@db.apache.org as an LDAP is sort of a db =)
 > A high-profile new project could help liven up DB some ;-)
 > -Brian

View raw message