Subject: Re: Fwd: Re: draft Java-api-12

From: Steven Sonntag <[email-masked]>
Date: Thu, 21 Dec 2000 13:30:33 -0700

Rob Weltman wrote:

>   It might be better instead to eliminate the current unsolicited
> notification methods and instead have methods to add and remove
> listeners for usolicited notifications. The implementation can then
> discard unsolicited notifications if there are no listeners. For
> example (I haven't thought this through completely yet):
>
> LDAPConnection
>
> public LDAPResponseListener addUnsolicitedNotificationListener(
> LDAPResponseListener listener )
>
> public void removeUnsolicitedNotificationListener(
> LDAPResponseListener listener )
>
> Rob
>

It seems natural to me that if unsolicited notifications are enabled on
a
listener, that the method LDAPListener.getMessageIDs() would include
message ID 0 in the list of message IDs, and that
LDAPConnection.abandon(0)
and LDAPConnection.abandon(listener) could be used to removeUnsolicited
notifications from a listener or listeners.  This raises some questions.

1) Should getMessageIDs show messageID 0 when unsolicited notification
are enabled?  (My vote is yes)

2) Should the draft allow abandon to be used to remove unsolicited
notifications?
(this means that message ID 0 is treated like a message that never
completes)

3) If number two is allowed, is removeUnsolicitedNotificationListener()
necessary?

-Steve

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 21 Dec 2000 12:57:01 -0800

>3) If number two is allowed, is removeUnsolicitedNotificationListener()

Is there a API requirement that requests are not generated with
message id 0 (as allowed within the protocol)?

Kurt

---

From: Rob Weltman <[email-masked]>
Date: Wed, 27 Dec 2000 21:53:27 -0800

> 3) If number two is allowed, is removeUnsolicitedNotificationListener()

  I think it is easier for a client to handle unsolicited notifications as out-of-band events rather than lumped together with "normal" solicited responses. In almost all cases I would expect a client to want to know immediately that an unsolicited notification had arrived rather than having to poll and distinguish between solicited and unsolicited notifications. The event listener model reflects the paradigm of immediate out-of-band notification of unsolicited messages. Having the unsolicited messages ALSO appear in the normal message queue is confusing, error-prone, and not very useful as far as I can tell.

Rob