RE: C API: minor comments

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

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

It can't. It may however, get *unsolicited* extended responses with
messageId 0. Currently, most clients don't expect this kind of response.
Hence, it is worthy to make a mention of it.

>Yes.  This should teach applications not to implicitly
>ignore unsolicited notifications.

Consider a simple application written using only the synchronous APIs
(typical case). How does the app know that the server is even sending
unsolicited notifications? It won't. This may cause the client library to
run out of memory due to queued up notifications. This is just one of the
reasons, IMO, for the default behavior of tossing notifications unless the
app sets an option to receive them.

-Anoop Anantha

-----Original Message-----
From: Kurt D. Zeilenga [mailto:kurt@boolean.net]
Sent: Monday, November 15, 1999 7:07 PM
To: Anoop Anantha (Exchange)
Cc: 'Mark Wahl'; mcs@netscape.com; howes@yahoo.com; Andy Herron
(Exchange); kurt@OpenLDAP.Org; ietf-ldapext@netscape.com
Subject: RE: C API: minor comments


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