Re: Search over referrals (Re: LAST CALL: draft-ietf-ldapext-ref erral-00.txt)

[dboreham@netscape.com (David Boreham)]

Alan Lloyd wrote:

<big snip>

Well, I didn't understand much of that, and I have
work to do, so no comment. But:

>         No I am not question yours - But I will generally question file
> based directory systems.  - RDBs do contain commitment services which we
> use - so that if someone pulls the plug on the server while updates (eg.
> 100s per second) are being performed then the DIB if supported by an RDB
> will remain intact - ie it will have integrity. I think that if a cached
> based file system directory is used as the DIB and someone pulls the
> plug when its updating then what state is the DIB in.

Right. If you take databases 101 you'll hear about theACID* tests. You're
saying that some databases meet
the ACID test, and some don't. Yours and mine do,
so we're in agreement. I don't think any major-league vendor
ships a server which isn't industrial strength today.
Seems that on this point you are tilting at windmills.

>         Is it hours of recovery and rebuild time. What DB commitment
> services are used - generally none . As said big corporates use RDBs for
> integrity of their business information. As directories will be used to
> support the business in the same and critical context - then surely the
> same information storage integrity should be used - Thats why we use and
> RDB it in our directory - with automatic indexing on all attributes  -
> for distributed performance.

Surely. I'm intrigued to know which vendors are selling
products which feature long recovery times.

My take on this is that databases which meet the
ACID test are a good thing; that they're just code and
testing; and a competent grad student could write one.
Beyond that, everything is emotion. Some folks think that
the database from <insert well-known RDBMS vendor
of choice here> is foolproof, therefore they want to use it.
Others don't care, they just want the directory server
to satisfy the ACID test, and have no interest in the
implementation. On this point we are agnostic. You can
use our database code, or you can use someone else's
database code. This saves on graying hairs due to
the aforementioned emotional swings.

Anyway, I still completely fail to see how this
debate has any bearing upon your LDAP vs X.500 thoughts.
One could surely implement an X.500 server with a
horrid database (say, use mercury delay lines and a
really noisy sense amplifier). Conversely, one could
implement an LDAP server over formally proven
database code, running on a (mythical) formally proven
processor.
The protocol is orthogonal to the storage mechanism.

--
*Atomicity, Consistency, Isolation, Durability.