Re: Objections to draft-ietf-ldapext-psearch-01.txt

[Mark Smith <mcs@netscape.com>]

Ed Reed wrote:
> ...
> Considerable industry experience with client-side
> caching of message stores and associated address
> book information suggests that for those kinds of
> human interface applications, a poll cycle on the
> order of minutes is adequate, and that with even
> reasonable design, random variations in the period
> of poll attempts by the clients will result in a smoothing
> of traffic and cpu loads on servers.  If the client
> already is holding an authenticated connection open
> to deal with queries, the poll can easily be inserted
> into the query queue without doubling the connections
> (and authentication operations) on the server, and
> without imposing serious state-ful management
> issues on the server tracking who wants what sent
> where.

There seems to be some confusion here:  Persistent Search does not
require a dedicated TCP/IP connection.  Clients are free to perform
other LDAP operations on the same connection.  If a client is keeping an
open LDAP connection for other reasons (and I believe most active
clients will) Persistent Search feels like a natural, low-overhead
mechanism for change notification.


> ... For the portable client, a periodic poll for changes (the
> very search that would be performed by the psearch)
> leaves coordination of who needs what where it
> should be - with the clients who care, and not with
> the server.

The client implementors I have talked to hate the idea of polling.  They
will poll if that is all we support, but they'd rather have something
better.

-- 
Mark Smith
Directory Architect / Netscape Communications Corp.
My words are my own, not my employer's.  Got LDAP?