Re: LDAP extensions for subtrees.

[Jim Sermersheim <JIMSE@novell.com>]

One way to address these issues would be to specify some additional client interaction mechanisms.  If I'm reading it right, the proposal is simply trying to cut down on wire traffic (maybe there are subtle sub-goals that I'm ignoring).  

The proposal could include a mechanism which would alert the client when anything out of the ordinary happens (acl restrictions, structural changes, other errors, etc).  With this alert (possibly just the extended response), information would need to be conveyed back to the client equal to the information the client would have, had it performed the operations singly by itself (which actions took place, what went wrong, etc).  I haven't thought about what these mechanisms would look like.  Along with this, there may be the need for a mechanism which allows the client to restart an operation where it left off (perhaps after correcting the problem).

If something like this isn't provided, either the extensions would need to carry scenario-based information to the server so that it can make all the decisions that a client normally makes (yuck), or the proposal would need to include lots of restrictive language, explaining how the server is to behave under various circumstances (almost equally yuck)

I'm not sure how non-problem things happen (referrals, aliases).  

Jim

 

>>> David Boreham <dboreham@netscape.com> 6/23/99 10:22:24 AM >>>

Bruce Greenblatt wrote:

> operations from a transaction log.  What do you think?  I think that it
> ought to be possible to save a snapshot of the LDAP database, store off a
> serialized sequence of operations, and then replay them, and come up with
> the same end result time after time.

This is precisely the worry I have with this proposal !
What if the database is 200Gbytes ? Do you tell your
customers to reserve 200Gbytes of space on the off-chance
that they'll want to delete a subtree one day ?