[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: FW: I-D ACTION:draft-armijo-ldap-treedelete-02.txt

Here are some requirements that I have in my experience building real world
LDAP applications that try to operate on an entire subtree.

- Provide user feedback as to the progress of the long lived operation.  In
many scenarios,
  a subtree delete operation may take a long period of time (many hours for
large subtrees).
  It is essential to have a progress bar move across the screen as the
entries are deleted.

- As the delete subtree crosses containers into other LDAP servers,
additional 
  authentication credentials may be required to be retrieved from the LDAP
client, in
  order to allow the operation to proceed.

- If the authenticated user has access to only a portion of the subtree to
be deleted, I
  think that it should be possible for the part of the subtree that is
possible to delete,
  to in fact be deleted.

- The list of entries that has been deleted by the operation should be
returned to the
  client.  An incremental list of deleted entries could be returned with
the progress
  indication above.

- It should be possible to "cancel" the delete subtree operation, just as
the long lived
  Search operation can be "abandoned".

- It should be possible to delete only certain types of entries from the
subtree.  For 
  example, delete all printer objects from the subtree.

I believe all of these requirements to be reasonable, but not met be the
draft as it stands.  I'm certainly willing to investigate an attempt to
support these requirements (i have a few more as well, but they are along
these lines) as a control, along the lines suggested by this draft.

Bruce

At 10:58 PM 11/18/99 -0800, Paul Leach (Exchange) wrote:
>
>
>> -----Original Message-----
>> From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com]
>> Sent: Thursday, November 18, 1999 7:49 PM
>
>> The question is, do you 
>> really think
>> that implementing a delete subtree is best implemented as a 
>> control?  It
>> seems so obvious to me that it isn't the best implementation.
>
>When you said it was just a matter of style, I took that to mean that you
>yourself thought that there wasn't much to choose between the two
>approaches.
>
>I agree that it could be done either way.
>
>We obviously thought that the control was the best/cleanest/most convenient
>implementation, because that's how we implemented it. It seemed to provide
>the maximum amount of code sharing between regular delete and tree delete.
> 
>> If you were
>> to have to change the definition from a yet to be 
>> standardized control to a
>> yet to be standardized extended operation, what do you 
>> believe the impact
>> would be on your product?
>
>We would have to throw away the existing implementation, for what appears to
>be mainly aesthetic improvements.
>
>Paul
>
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com