You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/05/21 23:34:45 UTC
Building an LDAP server is not an easy task (was: Re: [ApacheDS Webapps] Use Cases)
Yes we will get there and it takes time. However building an LDAP server is
very difficult and making sure
it is extensible while making it reliable and fast is beyond rocket
science. Our architecture is designed for
flexibility and we will see LDAP acquire new concepts that have existed in
the RDBMS world for years now.
LDAP will see a day when it has triggers, stored procedures, views and
queues very soon to make it more
useful than ever.
Just keep in mind that an LDAP server is both a network server and a
database server at the same time.
Most legacy LDAP servers are severely brittle. ApacheDS is something that
will brew over time but hopefully
when we get to that mark it will still be extensible so we can build on it
to take LDAP to places it's never
gone before. Also because of a flexible architecture we'll be able to
implement much more sophisticated
algorithms that give us an advantage in each respect.
LDAP servers today do no justice to the technology. I think we have a
chance to bring this protocol to the
21st century.
So let's not freak when people try to compare ApacheDS to other servers on
the basis of performance or other
metrics. All these aspects will be brought to par gradually together.
After all many people are a bit intimidated
by what we're doing. Let the passion and vision drive us not the need to
keep up with other servers around us
based on what they perceive to be the hottest aspect this month.
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.
Alex
On 5/21/07, Emmanuel Lecharny <el...@apache.org> wrote:
>
> Andrew C. Oliver a écrit :
>
> > Stefan Zoerner wrote:
> >
> >> Ole Ersoy wrote:
> >>
> >>>
> >>> Yeah - Would be great if they would just drop the whole thing
> >>> and go with something superior like ADS :-). They did it with
> >>> Geronimo, now it's ADS's turn.
> >>>
> >> I just talked about the WebApp. I do not think that ApacheDS is
> >> superior to TivoliDS yet. TivoliDS has a very solid persistence (DB2)
> >> and has some really large installations in production for ages.
> >>
> >> Greetings,
> >> Stefan
> >
> >
> > DB2's locking scheme isn't very good for assuring consistency on read
> > mostly systems.
> >
> I have seen DB2+TivoliDS used in a big company with more than 70 000 000
> entries. Stable, reliable. I wish ADS is half as good as TivoliDS + DB2 ;)
>
> Emmanuel
>
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS Webapps] Use Cases)
Posted by Jim Yang <ji...@safehaus.org>.
I want to add to Mark's comment. By not having to reinvent the wheel,
such as writing our own ldap stack, we are able to address other
problem domain. Thank you ApacheDS Developers!
On 5/22/07, Mark Swanson <ma...@scheduleworld.com> wrote:
> Alex Karasulu wrote:
> > Yes we will get there and it takes time. However building an LDAP
> > server is very difficult and making sure
> > it is extensible while making it reliable and fast is beyond rocket
> > science. Our architecture is designed for
> > flexibility and we will see LDAP acquire new concepts that have existed
> > in the RDBMS world for years now.
> > LDAP will see a day when it has triggers, stored procedures, views and
> > queues very soon to make it more
> > useful than ever.
>
>
> I'd like to chime in and say that the existing architecture enabled me
> to implement a form of triggers, stored procs, dynamic views, and a new
> way of handling indexes. Also, thanks to the flexibility of the design
> I was able to implement an entirely new back end (partition) based on an
> existing replicated clustered caching system.
>
> The point I'm trying to make is that I have no idea how I would have
> accomplished this without ADS. To be useful to me an LDAP server has to
> be extensible. ADS is extensible in exactly the way I (a humble software
> developer just trying to get LDAP stuff to work) needs it to be.
>
> Thank you (ADS developers) for making ADS.
>
> Cheers.
>
> --
> http://www.ScheduleWorld.com/
> Free Google Calendar synchronization with Outlook, Evolution,
> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.
>
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS Webapps] Use Cases)
Posted by Ersin Er <er...@gmail.com>.
On 5/22/07, Mark Swanson <ma...@scheduleworld.com> wrote:
> Alex Karasulu wrote:
> > Yes we will get there and it takes time. However building an LDAP
> > server is very difficult and making sure
> > it is extensible while making it reliable and fast is beyond rocket
> > science. Our architecture is designed for
> > flexibility and we will see LDAP acquire new concepts that have existed
> > in the RDBMS world for years now.
> > LDAP will see a day when it has triggers, stored procedures, views and
> > queues very soon to make it more
> > useful than ever.
>
>
> I'd like to chime in and say that the existing architecture enabled me
> to implement a form of triggers, stored procs, dynamic views, and a new
> way of handling indexes. Also, thanks to the flexibility of the design
> I was able to implement an entirely new back end (partition) based on an
> existing replicated clustered caching system.
We would be glad if you could share your experiences and codes (if
possible) on developing those constructs.
> The point I'm trying to make is that I have no idea how I would have
> accomplished this without ADS. To be useful to me an LDAP server has to
> be extensible. ADS is extensible in exactly the way I (a humble software
> developer just trying to get LDAP stuff to work) needs it to be.
>
> Thank you (ADS developers) for making ADS.
We thank you for using and supporting ApacheDS.
BTW, I feel a cool testimonal here ;-)
> Cheers.
>
> --
> http://www.ScheduleWorld.com/
> Free Google Calendar synchronization with Outlook, Evolution,
> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.
>
--
Ersin
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS
Webapps] Use Cases)
Posted by Emmanuel Lecharny <el...@apache.org>.
Mark Swanson a écrit :
> I'd like to chime in and say that the existing architecture enabled me
> to implement a form of triggers, stored procs, dynamic views, and a
> new way of handling indexes. Also, thanks to the flexibility of the
> design I was able to implement an entirely new back end (partition)
> based on an existing replicated clustered caching system.
Thanks a lot :)
>
> The point I'm trying to make is that I have no idea how I would have
> accomplished this without ADS. To be useful to me an LDAP server has
> to be extensible. ADS is extensible in exactly the way I (a humble
> software developer just trying to get LDAP stuff to work) needs it to be.
That's a great news for us that you successfully implemented what you
needed using ADS. We just designed this server (I say 'we', but this was
mainly Alex hard work !) to allow users to extend it to a point it fits
their needs.
Thank you very much for having validating the vision Alex had 5 years
ago, and that we are now trying to stabilize and carry to the next big
step : ADS in production all obver the world :)
>
> Thank you (ADS developers) for making ADS.
And thanks again to you (ADS users) for making ADS being used,
discovering bugs that the next users won't have as soon as we will fix
them. Apache is just about this : developper and users, and also users
becoming committers to help new users, and so on!
Feel free to participate to the effort, Mark !
Emmanuel
Re: Building an LDAP server is not an easy task
Posted by Ole Ersoy <ol...@gmail.com>.
Yeah Mannn - I'm just about done
with the LDAP DAS I think, and without
ADS's Dynamic schema capabilities I think
I would be playing with the RDB DAS right now.
Thanks Guys!! ADS is Cooollll!!!
- Ole
Mark Swanson wrote:
> Alex Karasulu wrote:
>> Yes we will get there and it takes time. However building an LDAP
>> server is very difficult and making sure
>> it is extensible while making it reliable and fast is beyond rocket
>> science. Our architecture is designed for
>> flexibility and we will see LDAP acquire new concepts that have
>> existed in the RDBMS world for years now.
>> LDAP will see a day when it has triggers, stored procedures, views and
>> queues very soon to make it more
>> useful than ever.
>
>
> I'd like to chime in and say that the existing architecture enabled me
> to implement a form of triggers, stored procs, dynamic views, and a new
> way of handling indexes. Also, thanks to the flexibility of the design
> I was able to implement an entirely new back end (partition) based on an
> existing replicated clustered caching system.
>
> The point I'm trying to make is that I have no idea how I would have
> accomplished this without ADS. To be useful to me an LDAP server has to
> be extensible. ADS is extensible in exactly the way I (a humble software
> developer just trying to get LDAP stuff to work) needs it to be.
>
> Thank you (ADS developers) for making ADS.
>
> Cheers.
>
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS Webapps] Use Cases)
Posted by Alex Karasulu <ak...@apache.org>.
Boy what can I say? Thanks for your kind words Mark. You're one of our
first most loyal users and you have dealt with ApacheDS issues for a long
time. I'm glad to see you getting a benefit for sticking with us and our
vision for so long.
Alex
On 5/22/07, Mark Swanson <ma...@scheduleworld.com> wrote:
>
> Alex Karasulu wrote:
> > Yes we will get there and it takes time. However building an LDAP
> > server is very difficult and making sure
> > it is extensible while making it reliable and fast is beyond rocket
> > science. Our architecture is designed for
> > flexibility and we will see LDAP acquire new concepts that have existed
> > in the RDBMS world for years now.
> > LDAP will see a day when it has triggers, stored procedures, views and
> > queues very soon to make it more
> > useful than ever.
>
>
> I'd like to chime in and say that the existing architecture enabled me
> to implement a form of triggers, stored procs, dynamic views, and a new
> way of handling indexes. Also, thanks to the flexibility of the design
> I was able to implement an entirely new back end (partition) based on an
> existing replicated clustered caching system.
>
> The point I'm trying to make is that I have no idea how I would have
> accomplished this without ADS. To be useful to me an LDAP server has to
> be extensible. ADS is extensible in exactly the way I (a humble software
> developer just trying to get LDAP stuff to work) needs it to be.
>
> Thank you (ADS developers) for making ADS.
>
> Cheers.
>
> --
> http://www.ScheduleWorld.com/
> Free Google Calendar synchronization with Outlook, Evolution,
> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.
>
Re: Building an LDAP server is not an easy task
Posted by Ole Ersoy <ol...@gmail.com>.
Jim,
You would not by chance happen to know of a GPL
licensed open source implementation would you :-)
I think the part about this behavior that is disrespectful
to the Apache Directory community is that you know that it is
targeting having this type of capability, and every time
you see someone looking for it, you slide in an opportunity
to steer them towards "A Googled open source" implementation,
which has the potential of diverting attention from Apache Directory
code.
It seems like you have have had much benefit
from the ApacheDS implementation, and you created something
on top of it that you licensed GPL making it completely
incompatible with our efforts here.
I personally have 0 interest in a virtual directory at the moment,
but I know many of the developers here do, so how about
we give them a break and show some appreciation for what
they have enabled you to do.
Cheers,
- Ole
Jim Yang wrote:
> It is definitely possible using ApacheDS, but you have implement your
> extension using ApacheDS interceptor. What you mentioned is a well
> known concept called virtual directory. If you have the resources to
> implement this, I would recommend that you do implement it. That would
> be a great addition to ApacheDS. If you don't want to write the code
> yourself, you can try to google it to see if there is an open source
> virtual directory implementation out there.
>
> On 5/24/07, Eric J. Christeson <Er...@ndsu.edu> wrote:
>> On Tue, May 22, 2007 at 04:42:09PM -0400, Mark Swanson wrote:
>> > I'd like to chime in and say that the existing architecture enabled
>> me to
>> > implement a form of triggers, stored procs, dynamic views, and a
>> new way of
>> > handling indexes. Also, thanks to the flexibility of the design I
>> was able
>>
>> I'm interested in how easy/difficult this was. We're looking at a
>> project
>> which would present an LDAP interface to an SQL database backend.
>> Without
>> getting into too much detail, the idea is that we want to present an LDAP
>> interface to an SQL database backend that contains identity
>> information. The
>> LDAP interface will allow authorized admins to update information on
>> identities they are responsible for with familiar tools, while the SQL
>> backend is desirable for updating from our authoritative source.
>> I've been looking at writing a backend for OpenLDAP, but upon seeing
>> your message, ApacheDS might be a better alternative.
>>
>> Thanks,
>> ERic
>>
>> --
>> Eric J. Christeson <Er...@ndsu.edu>
>> Information Technology Services (701) 231-8693 (Voice)
>> Room 242C, IACC Building
>> North Dakota State University, Fargo, ND 58105-5164
>>
>> PHP is a minor evil perpetrated and created by incompetent amateurs,
>> whereas Perl is a great and insidious evil, perpetrated by skilled
>> but perverted professionals. - Jon Ribbens
>>
>>
>
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS
Webapps] Use Cases)
Posted by Emmanuel Lecharny <el...@apache.org>.
Jim Yang a écrit :
> It is definitely possible using ApacheDS, but you have implement your
> extension using ApacheDS interceptor. What you mentioned is a well
> known concept called virtual directory. If you have the resources to
> implement this, I would recommend that you do implement it. That would
> be a great addition to ApacheDS. If you don't want to write the code
> yourself, you can try to google it to see if there is an open source
> virtual directory implementation out there.
Jim, I would appreciate a lot, as the Chairman of this project, that you
don't use this mailing list to promote your own product. You can
perfectly reply privatly to Eric and told him about it, but please keep
this ML Apache Directory Server focused. Your last sentence is totally
out of scope.
Apache is *not* a commercial entity.
Thanks.
>
> On 5/24/07, Eric J. Christeson <Er...@ndsu.edu> wrote:
>
>> On Tue, May 22, 2007 at 04:42:09PM -0400, Mark Swanson wrote:
>> > I'd like to chime in and say that the existing architecture
>> enabled me to
>> > implement a form of triggers, stored procs, dynamic views, and a
>> new way of
>> > handling indexes. Also, thanks to the flexibility of the design I
>> was able
>>
>> I'm interested in how easy/difficult this was. We're looking at a
>> project
>> which would present an LDAP interface to an SQL database backend.
>> Without
>> getting into too much detail, the idea is that we want to present an
>> LDAP
>> interface to an SQL database backend that contains identity
>> information. The
>> LDAP interface will allow authorized admins to update information on
>> identities they are responsible for with familiar tools, while the SQL
>> backend is desirable for updating from our authoritative source.
>> I've been looking at writing a backend for OpenLDAP, but upon seeing
>> your message, ApacheDS might be a better alternative.
>>
>> Thanks,
>> ERic
>>
>> --
>> Eric J. Christeson <Er...@ndsu.edu>
>> Information Technology Services (701) 231-8693 (Voice)
>> Room 242C, IACC Building
>> North Dakota State University, Fargo, ND 58105-5164
>>
>> PHP is a minor evil perpetrated and created by incompetent amateurs,
>> whereas Perl is a great and insidious evil, perpetrated by skilled
>> but perverted professionals. - Jon Ribbens
>>
>>
>
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS Webapps] Use Cases)
Posted by Jim Yang <ji...@safehaus.org>.
It is definitely possible using ApacheDS, but you have implement your
extension using ApacheDS interceptor. What you mentioned is a well
known concept called virtual directory. If you have the resources to
implement this, I would recommend that you do implement it. That would
be a great addition to ApacheDS. If you don't want to write the code
yourself, you can try to google it to see if there is an open source
virtual directory implementation out there.
On 5/24/07, Eric J. Christeson <Er...@ndsu.edu> wrote:
> On Tue, May 22, 2007 at 04:42:09PM -0400, Mark Swanson wrote:
> > I'd like to chime in and say that the existing architecture enabled me to
> > implement a form of triggers, stored procs, dynamic views, and a new way of
> > handling indexes. Also, thanks to the flexibility of the design I was able
>
> I'm interested in how easy/difficult this was. We're looking at a project
> which would present an LDAP interface to an SQL database backend. Without
> getting into too much detail, the idea is that we want to present an LDAP
> interface to an SQL database backend that contains identity information. The
> LDAP interface will allow authorized admins to update information on
> identities they are responsible for with familiar tools, while the SQL
> backend is desirable for updating from our authoritative source.
> I've been looking at writing a backend for OpenLDAP, but upon seeing
> your message, ApacheDS might be a better alternative.
>
> Thanks,
> ERic
>
> --
> Eric J. Christeson <Er...@ndsu.edu>
> Information Technology Services (701) 231-8693 (Voice)
> Room 242C, IACC Building
> North Dakota State University, Fargo, ND 58105-5164
>
> PHP is a minor evil perpetrated and created by incompetent amateurs,
> whereas Perl is a great and insidious evil, perpetrated by skilled
> but perverted professionals. - Jon Ribbens
>
>
Re: Building an LDAP server is not an easy task (was: Re:
[ApacheDS Webapps] Use Cases)
Posted by "Eric J. Christeson" <Er...@ndsu.edu>.
On Tue, May 22, 2007 at 04:42:09PM -0400, Mark Swanson wrote:
> I'd like to chime in and say that the existing architecture enabled me to
> implement a form of triggers, stored procs, dynamic views, and a new way of
> handling indexes. Also, thanks to the flexibility of the design I was able
I'm interested in how easy/difficult this was. We're looking at a project
which would present an LDAP interface to an SQL database backend. Without
getting into too much detail, the idea is that we want to present an LDAP
interface to an SQL database backend that contains identity information. The
LDAP interface will allow authorized admins to update information on
identities they are responsible for with familiar tools, while the SQL
backend is desirable for updating from our authoritative source.
I've been looking at writing a backend for OpenLDAP, but upon seeing
your message, ApacheDS might be a better alternative.
Thanks,
ERic
--
Eric J. Christeson <Er...@ndsu.edu>
Information Technology Services (701) 231-8693 (Voice)
Room 242C, IACC Building
North Dakota State University, Fargo, ND 58105-5164
PHP is a minor evil perpetrated and created by incompetent amateurs,
whereas Perl is a great and insidious evil, perpetrated by skilled
but perverted professionals. - Jon Ribbens
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS
Webapps] Use Cases)
Posted by Mark Swanson <ma...@ScheduleWorld.com>.
Alex Karasulu wrote:
> Yes we will get there and it takes time. However building an LDAP
> server is very difficult and making sure
> it is extensible while making it reliable and fast is beyond rocket
> science. Our architecture is designed for
> flexibility and we will see LDAP acquire new concepts that have existed
> in the RDBMS world for years now.
> LDAP will see a day when it has triggers, stored procedures, views and
> queues very soon to make it more
> useful than ever.
I'd like to chime in and say that the existing architecture enabled me
to implement a form of triggers, stored procs, dynamic views, and a new
way of handling indexes. Also, thanks to the flexibility of the design
I was able to implement an entirely new back end (partition) based on an
existing replicated clustered caching system.
The point I'm trying to make is that I have no idea how I would have
accomplished this without ADS. To be useful to me an LDAP server has to
be extensible. ADS is extensible in exactly the way I (a humble software
developer just trying to get LDAP stuff to work) needs it to be.
Thank you (ADS developers) for making ADS.
Cheers.
--
http://www.ScheduleWorld.com/
Free Google Calendar synchronization with Outlook, Evolution,
cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS
Webapps] Use Cases)
Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On May 21, 2007 6:19:27 PM -0400 Alex Karasulu <ak...@apache.org>
wrote:
> 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.
Works for me. :)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS Webapps] Use Cases)
Posted by Alex Karasulu <ak...@apache.org>.
On 5/21/07, Quanah Gibson-Mount <qu...@zimbra.com> wrote:
>
>
>
> --On May 21, 2007 5:34:45 PM -0400 Alex Karasulu <ak...@apache.org>
> wrote:
>
>
> > 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
> already...).
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.
Alex
Re: Building an LDAP server is not an easy task (was: Re: [ApacheDS
Webapps] Use Cases)
Posted by Quanah Gibson-Mount <qu...@zimbra.com>.
--On May 21, 2007 5:34:45 PM -0400 Alex Karasulu <ak...@apache.org>
wrote:
> 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. 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). 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
already...).
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration