RE: C API: minor comments

["Kurt D. Zeilenga" <kurt@boolean.net>]

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		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>