[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