Re: LDAP extensions for subtrees.

[Bruce Greenblatt <bgreenblatt@dtasi.com>]

At 11:00 AM 6/22/99 -0600, Jim Sermersheim wrote:
>So these operations are atomic in the sense that a single operation is
>issued, as opposed to atomic in the sense that the data specified
>(subtree or filtered subtree) is to be treated as an atomic unit,
>correct?  

That's pretty much all that I mean.  In the sense that you are trying to
"serialize" the LDAP operations, I would think that you'd consiser one of
these operations as a single entity so that other operations couldn't
interfere with the end result.  The primary point of this draft is that:

- these are common requirements for LDAP clients
- it is too cumbersome and time consuming to issue the commands individually

For example, my copy subtree routine using the existing LDAP API takes
about 13 minutes to copy a subtree of 4000 objects.  In this scenario, I'm
running Netscape DS 3.01 on a 300 Mhz PII, and the client and server are on
the same machine.  I can imagine that the DS could figure out a more
efficient way to carry this out internally than making the LDAP client
retrieve every object in the subtree, synthesize a new copy of the object,
and then transmit the new object back to the DS.

Bruce

>
>Maybe the word atomic carries more meaning than was intended and could
>be substituted with a less loaded word.
>
>>>> Bruce Greenblatt <bgreenblatt@dtasi.com> 6/22/99 9:56:04 AM >>>
>At 08:19 AM 6/22/99 -0700, David Boreham wrote:
>>
>>
>>Bruce Greenblatt wrote:
>>
>>> Thanks for the feedback.  This intention of the draft is that the
>SOS
>>> operations are to have the same end result as if the LDAP client
>had
>>> submitted a stream of standard LDAP operations.  So, you can't
>delete
>>
>>Isn't this at odds with the requirement that the
>>tree operation be atomic ?
>
>I don't think so.  The operation is just atomic from the client
>perspective.  It is up to the server to make sure that the result is
>correct.
>
>>A client submitting a stream of deletes can
>>see one fail half way through the sequence.
>>
>>
>
>Only if the client submits each operation synchronously, and waits for
>the
>result.  Since the operation can fail for any number of reasons, not
>just
>access control.  If the client wants to delete an entire container,
>why
>should it have to search the subtree, retrieve all of the entries, and
>then
>delete them individually?  This make very little logical sense to me.
>
>Bruce
>
>>
>
>
>