[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: FW: I-D ACTION:draft-armijo-ldap-treedelete-02.txt
At 08:37 AM 11/22/99 +0100, Helmut Volpers wrote:
>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.
I don't think that's what I mean... Of course, with the standardized
operations at our disposal, that is the only way to delete a subtree right
now.
>>
>> - 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
It is much easier to say that all you need to have is the additional access
right to "delete_subtree" than to get it implemented. Currently, it is
possible to have different access control information attached to each
entry in the subtree being deleted. I think that the modifyDN operation is
much different, as it leaves all of the entries in the subtree intact, and
only makes a change at the root of the subtree, since there is not really a
DN attribute for each entry.
>>
>> - 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.
This is certainly one perspective. I tend to disagree. I should be able
to have a delete subtree operation that has the same impact as if I had
performed a subtree search, and individually deleted all of the entries
that were returned. It seems to me that to restrict the delete subtree
operation to only work when all of the entries are contained on a single
LDAP server, in which all of the entries are accessible to the one identity
severely limits its usefulness. All that will result is to have an
operation that in general will rarely be able to work.
>>
>> - 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.
So. Is the client point of view, i.e. the designer of LDAP applications
not valid?
>>
>> - 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.
That's exactly the case. This is the same problem that we have today in
the search operation. We can apply the exact same logic and intelligence
in dealing with a delete subtree, as we do in dealing with a search subtree.
>>
>> - 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.
As I said before, I don't think that the delete subtree and the ModifyDN
are analogous. This is (should be) no big deal to do a rollback.
Databases have been doing this since the 70s. The server should be able to
have a consistent state.
>>
>> - 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.
>
This is completely bogus. I put entries in the tree in such a way that
they are easy for the administer to manage. They are not placed in the
tree in such a way that they are easy for the LDAP server to delete. For
example, if a printer is the one that is used by the technical writers, I
might put it in the tree in such a way that it is convenient to give rights
to the technical writers. Each decision on DIT design is very dependent on
the environment, and the common operations and applications that make use
of the directory. We shouldn't force LDAP designs into a particular
pattern so that a delete subtree is easy. There's nothing wrong with
wanting to delete all of the entries in a subtree that meet certain
criteria. I don't see how implementing such a problem would have an impact
on "referential integrity".
>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
>Attachment Converted: "C:\eudora\Attach\Helmut.Volpers9.vcf"
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com