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

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

Hi Bruce,

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

I think you mean when you have a client operation delete_subtree which
make a big
search and then delete one entry after the other.
> 
> - 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.

A delete_subtree can be implemented by a server like a move (for
example)modifyDN with new superior.
You only need an additional access right for delete_subtree and it
should be
in one naming context in one server. So if you have the right to
delete_subtree
you can 
> 
> - 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.

I don't think so if you have the right to delete_subtree the server will
delete the
tree completely or it fails and the tree still exists.
> 
> - 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.

I think all this is the client point of view what can happen if I search
the tree
and send a lot of delete operations.
> 
> - 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.

That means if I delete a subtree of 100.000 I have to give back the
100.000 entries
to the user? A lot of applications will have problems with result-sizes
like that.
> 
> - It should be possible to "cancel" the delete subtree operation, just as
> the long lived
>   Search operation can be "abandoned".

And the server will have a consistent state. I don't like the idea of an
abondon to 
update operations. When I make a modifyDN with new superior (move) the
server
also say success (then the complete tree is moved) or noSuccess then
everything
should be as before of the operation.
> 
> - It should be possible to delete only certain types of entries from the
> subtree.  For
>   example, delete all printer objects from the subtree.

Then put them in a special subtree.
Or what I prefer implement a client delete_subtree and you have all the
control
in the administrative client and you don't need to implement a
delete_subtree
in the server, because there are many cases where it is not easy to
check referential
integrity and other problems you can get with a operation like this. I
think making a 
modifyDn with new superior to a trash folder and then deleting the
subtree with
an administrative client should be possible with most server
implementations
and makes it easy.

Bye Helmut
> 
> 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

begin:vcard 
n:Volpers;Helmut
tel;fax:+49-89-636-45860
tel;work:+49-89-636-46713
x-mozilla-html:FALSE
url:http://www.siemens.com/bus-com
org:Siemens AG
adr:;;;Munich;;81730;Germany
version:2.1
email;internet:Helmut.Volpers@icn.siemens.de
title:Directory Server Architect
fn:Helmut Volpers
end:vcard