Re: Multiple extended responses per request

[steve fisher <s.a.fisher@btintenet.com>]

-----Original Message-----
From: David Boreham <dboreham@netscape.com>
To: 'ietf-ldapext@netscape.com' <ietf-ldapext@netscape.com>
Date: 14 September 1999 16:23
Subject: Re: Multiple extended responses per request


>Gil Kirkpatrick wrote:
>
>> If the purpose is to provide progress information to the client, doesn't
>> this scheme generate an inordinate amount of traffic, e.g. in your
example
>> of the tree delete, a packet per entry in the tree being deleted?
>

You could use percentage indicators.

>I wonder if this is a practical problem ?
>
>Another idea I've heard
>discussed which _could_ produce less traffic is to allow the
>client to monitor the progress of long-running operations
>like this via magic DIT entries. Somehow an entry would be
>created for the operation (e.g. long search, long subtree
>delete). That entry would have attribute values which tell
>the client how much progress has been made by the server
>in processing the operation. I'm not sure if this is a
>terribly good idea or not. It's obviously quarter-baked.

If we are to use a client-driven approach then, although this looks like a
nice simple mechanism, the function that it provides is a management one. If
this was the only type of management activity it may be worth considering,
but I doubt whether this would be the case. It may be better to use/define
managed objects instead of magic DIT entries and use the measuring
facilities of existing managementn protocols , incorporate a management
client in with the ldap client, and co-ordinate the operation of the two
clients.