Subject: RE: C API: minor comments

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 19:07:01 -0800

At 04:29 PM 11/15/99 -0800, Anoop Anantha (Exchange) wrote:
>2] It might also help if we clarify that an application looking for
>LDAP_RES_UNSOLICITED messages MAY get back messages of type
>LDAP_RES_EXTENDED.

If the client always uses non-zero messageIDs in requests,
how could it get a solicited extended response of message
with message id of zero?

>3] A client library MUST toss unsolicited responses with non-zero
>messageIds.

Though this would hide the existance of such messages from the
application (not allowing it to report the problem to the user),
it is likely a sane practice (as being malformed messages).

>For unsolicited notifications with zero messageId, I would
>suggest the default behavior be to toss them unless the app has explicitly
>asked for them.

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).

>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.

>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.

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Nov 1999 15:32:26 -0500

"Kurt D. Zeilenga" wrote:
> ...

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).

> The default, IMO, should be to queue them.

Agreed.

> 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?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Nov 1999 12:51:40 -0800

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
> 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

Not that I am aware of.

Kurt