Re: C API: minor comments

[Mark Smith <mcs@netscape.com>]

"Kurt D. Zeilenga" wrote:
> ...
> In a non-threaded environment, the application may use polling of
> responses (using ldap_result) to implement multiplexing.  I'd
> don't think unsolicited notifications should be tossed as this
> would disallow polling for them.  I also think it unwise to
> encourage unsolicited notifications from being ignored.  If the
> app chooses to toss them, that's their choice.  But the API,
> I believe should provide them UNLESS the app explicitly
> says to toss them (using some client control or option).

I agree (although I am sure many applications have been written that do
not handle unsolicited notifications -- simply because most servers do
not send them routinely).


> 
> >We could provide an option to queue up these notifications
> >for applications which need them.
> 
> I prefer to add an option to disable queuing of unsolited notifications.
> The default, IMO, should be to queue them.

Agreed.


> 
> >If we don't do this, simple applications
> >which know nothing about unsolicited notifications will not process them and
> >the notifications may continue to queue up until the client runs out of
> >memory.
> 
> Yes.  This should teach applications not to implicitly
> ignore unsolicited notifications.

Ouch.  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?  The only one that is defined is the notice of disconnection
from 2251.  Are there any other examples in practice?

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