On 5/21/07, Quanah Gibson-Mount <email@example.com> wrote:
--On May 21, 2007 5:34:45 PM -0400 Alex Karasulu <firstname.lastname@example.org>
> LDAP servers today do no justice to the technology. I think we have a
> chance to bring this protocol to the
> 21st century.
> Eventually we'll be at the same level as other servers out there. And
> hopefully those other efforts will start to
> take LDAP where we want it to go just because they want to remain
> competitive with our feature set.
I've discussed various feature enhancements to LDAP in general with Howard
Chu over the years. One of the major problems is if you want to stay RFC
compliant or not.
This is not necessarily true. You can still introduce these rich integration tier
constructs into LDAP without breaking with protocol compliance. We will do
this and still be compliant with our Open Group certification. There is sufficient
room for extending LDAP while leveraging existing constructs in the RFCs.
This is just an analogy but consider those RDBMS' which are SQL 92 compliant
yet all of them have different mechanisms for implementing a stored procedure
while the same mechanism for executing the SP exists in the standard.
In our perpendicular plane (the LDAP plane) we have implemented stored
procedures as Java static methods that operate on the DIT. Users can implement
any kind of SP logic and use a server side JNDI provider to access the DIT as
they need to. However we use a standard mechanism to invoke the SP from the
client: meaning we use an extended operation to expose the SP. This complies
with LDAPv3 and yet it introduces a new construct LDAP has never seen before.
We owe this advance in part to Java's dynamic nature to store and load classes
from the DIT where users without a restart can add their own stored procedures.
So as you can see we do not break with the protocol and are still complaint as
certified by the Open Group yet we are able to introduce these new features that
the LDAP community is hungry for.
The name of the game is to get people to use LDAP for data that belongs in a
Directory rather than them just give up with antiquated servers that can at best
serve as a store for white pages.
The way in which the protocol was written makes it
particularly difficult to add new features while remaining compliant (that
is in large part why the overlay system was developed for OpenLDAP). What
I've suggested a few times, is to throw away LDAP and start over with
something new (What I generally call SDAP or SMART DAP).
That's not going to happen. We just need to be a bit more creative and see opportunities.
I btw had started working with the OpenLDAP code base years ago (about 7 years ago)
before I starting working on ApacheDS. This is when I realized that Java had more than
the compile once run anywhere advantage. Dynamic binding is what allowed us to implement
SPs in ApacheDS overnight. With OpenLDAP it was almost impossible but this was not due
to it's inherent design but the language chosen.
Incidentally this and their brittle SUN DS is why the SUN folks woke up and decided to start
work on OpenDS. They see the obvious advantages and have verified my initial premise
almost 6 years ago. Perhaps the OpenLDAP forks can come to this same conclusion to help
us build a better server together ;).
Of course, then
one would no longer have an LDAP server, and I'm guessing corporate vendors
would be slow to adopt (given the slow pace of their LDAP v3 adoption
Yeah this is not going to happen or if it does it will take another 2 decades. The key to having
an LDAP reniassance is simple really. Here's the formula IMO:
(1) Resusitate some critical X.500 concepts that the LDAP creators chopped out of LDAP
to oversimplify it: namely talking about the administrative model here and not OSI stack.
Kurt began doing this with couple RFCs like the one for subentries and collective attributes.
(2) Provide some solid tooling to simplify and accomodate the lack of knowledge around LDAP
and X.500 concepts which LDAP is built upon. The RDBMS world is rich with tooling support
yet the LDAP world has virtually none.
(3) Provide the rich integration tier constructs many RDBMS developers are accustomed to yet
transposed to the LDAP plane. These constructs include:
(a) LDAP Stored Procedures
(b) LDAP Triggers
(c) LDAP Views
(d) LDAP Queues (to interface with MOMs)
*** incidentally we use the X.500 admin model to implement these features
If these critical peices of the puzzle are solved then we'll see the Directory come back as the swiss army
knife of integration it was intended to be. Right now Directories are stuck serving out white pages and
admins are still scratching their heads when trying to figure out how to remove users from groups when
users are deleted to maintain referrential integrity. Why have we messed this up so bad?
The key to solving the integration problems with LDAP which will plauge the enterprise for the next 30 years
lie in these critical features. If we cannot see this and correct our path together then our chances
of renewing the demand for LDAP are lost as new half baked technologies emerge to solve these problems
and clutter the vision of those that should be deciding on LDAP.