RE: C API: minor comments

["Anoop Anantha (Exchange)" <anoopa@Exchange.Microsoft.com>]

We might think that unsolicited notifications are minimal under usual
conditions. But consider a server which sends notices of idle disconnection
every 10 mins into an idle session to clients written using synchronous
APIs. These messages will continue to pile up over a period of time because
the client has no way of processing these. This is just one example.
Moreover, since we don't know how unsolicited notifications will be used in
future, a memory leak, however small it may seem, is problematic in the long
run.

Either we should have a way for synchronous APIs to get at these
notifications (not elegant) or we should have the client library toss these
unless the app explicitly asks for it.

-Anoop

-----Original Message-----
From: Kurt D. Zeilenga [mailto:kurt@boolean.net]
Sent: Tuesday, November 16, 1999 12:52 PM
To: Mark Smith
Cc: Anoop Anantha (Exchange); 'Mark Wahl'; howes@yahoo.com; Andy Herron
(Exchange); kurt@OpenLDAP.Org; ietf-ldapext@netscape.com
Subject: Re: C API: minor comments


Mark Smith wrote:
> Ouch.

I guess I should have put a :-) on that comment.  :-)

> But I agree that they should be queued by default.  Do we really
> expect so many unsolicited notifications to be sent so as to overwhelm a
> client? 

No.  I hope that unsolicited notifications would be minimal under
usual conditions.  The only time I could think that a client
could get overwhelmed is that if it enabled some feature which
caused lots of unsolicited notifications (such as enabling
some sort of monitoring) to be sent.  Of course, clients enabling
such features should be expecting the notifications.  Also, note,
with the introduction of ExtendedPartialResponse, such (ab)uses
of unsolicited notification might never be created.

> The only one that is defined is the notice of disconnection
> from 2251.  Are there any other examples in practice?

Not that I am aware of.

Kurt