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

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

> -----Original Message-----
> From:	dboreham@netscape.com [SMTP:dboreham@netscape.com]
> Sent:	Wednesday, April 08, 1998 9:51 AM
> To:	Alan Lloyd
> Cc:	ietf-ldapext@netscape.com
> Subject:	Re: Search over referrals (Re: LAST CALL:
> draft-ietf-ldapext-ref				erral-00.txt)
> 
> 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.
> 
	Well no - some systems use files and RAM cache to get
performance. So I think that customers should know that and do a "pull
the plug test" and see what the restart times are and what state the DIB
is in afterwards. 

> >         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.
> 
	Ten minutes is a long time  in a stock exchange, a bank or
fighting a war.



> 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.
> 
	I wonder why Oracle and Ingres - didnt think of that :-) 

> 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.
> 
	Not emotion - I just like to see distributed information systems
work with good integrity. Thats engineering principles.


> 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.
	Yes agree - but when one has distributed storage systems working
under a naming context that have to be efficiently navigated through and
contain binary and complex attributes that have to be seached for - the
two are very related - In object oriented design the protocols used are
related to the objects (and the distribution and storage of the objects)
> --
> *Atomicity, Consistency, Isolation, Durability.
	Thanks for that

	regards aln