Subject: Re: draft Java-api-12

From: Rob Weltman <[email-masked]>
Date: Tue, 28 Nov 2000 08:43:29 -0800

Steve Sonntag wrote:

>  I have been thinking about the specification forunsolicited notifications in the Java api draft version 12. The draft has two methods in LDAPConnectionthat are concerned with Unsolicited Notifications: one sets a flag indicating whether to keep or discardunsolicited notifications:    setUnsolocitedNotifications(boolean flag)the other gets the value of the flag Unsolicited notifications are retrieved by callingthe getResponse(0) method from one of theListener classes.  the "0" indicates message ID 0. The problem is that a listener has association witha connection only when a request is in progressusing that listener.  A listener in an application with5 connections open could be servicing requestson all five connections or on none of them.  UsinggetResponse from the listener class to getUnsolicited notifications is problematic.  If no requestsare outstanding on the listener, there is no associationwith a connection, so it is not possible to checkfor unsolicited notifications. It would seem that the only reliable way to check forand get unsolicited notifications would be throughthe LDAPConnection class itself and not through the listener.classes. Two more LDAPConnection methods - ugh, butperhaps necessary? Anyone have any better ideas? -Steve   ------------------------
> Steve Sonntag
> Novell, Inc., the leading provider of Net services software

  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 addUnsolicitedNotificationListener( LDAPResponseListener listener )

Rob

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 28 Nov 2000 08:51:15 -0800

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

When using the low level ("asynchronous") API, unsolicited
notifications can (and should) be handled just like any other
response message.  I do agree that the higher level ("synchronous")
API which needs some reworking.

---

From: Steven Sonntag <[email-masked]>
Date: Tue, 28 Nov 2000 13:52:49 -0700

Rob Weltman wrote:

> Steve Sonntag wrote:
>
>>  I have been thinking about the specification forunsolicited
>> notifications in the Java api draft version 12. The draft has two
>> methods in LDAPConnectionthat are concerned with Unsolicited
>> Notifications: one sets a flag indicating whether to keep or
>> discardunsolicited notifications:
>> setUnsolocitedNotifications(boolean flag)the other gets the value of
>> the flag Unsolicited notifications are retrieved by callingthe
>> getResponse(0) method from one of theListener classes.  the "0"
>> indicates message ID 0. The problem is that a listener has
>> association witha connection only when a request is in progressusing
>> that listener.  A listener in an application with5 connections open
>> could be servicing requestson all five connections or on none of
>> them.  UsinggetResponse from the listener class to getUnsolicited
>> notifications is problematic.  If no requestsare outstanding on the
>> listener, there is no associationwith a connection, so it is not
>> possible to checkfor unsolicited notifications. It would seem that
>> the only reliable way to check forand get unsolicited notifications
>> would be throughthe LDAPConnection class itself and not through the
>> listener.classes. Two more LDAPConnection methods - ugh, butperhaps
>> necessary? Anyone have any better ideas? -Steve
>> ------------------------
>> Steve Sonntag
>   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
>

I like your idea Rob, it fits much better with the rest of the
architecture.

I have a few questions:

Are multiple UnsolicitedNotificationListeners allowed on a given
connection.
What would the behavior be in such a situation.  The name seems to
indicate
that multiple are allowed.

My take is that only one unsolicited notification listener exists for a
given connection.
Of course, that listener may be servicing multiple connections (using
the first method
to create it).  I am not sure of the purpose for the second method.
Would the first method be more clearly named
"setUnsolicitedNotificationListener",
implying there is only one?

I assume that getResponse() blocks if no unsolicited notifications are
available.

getMessageIds would return an array with 0 being one of the message ID
values.

Could this listener be merged with a regular listener?  There seems no
reason why it
couldn't.

How does one remove an unsolicited notification listener, or was your
second
method meant to be a delUnsolicitedNotificationListener?

-Steve

--
------------------------
Steve Sonntag

---

From: Rob Weltman <[email-masked]>
Date: Tue, 28 Nov 2000 12:58:29 -0800

> method meant to be a delUnsolicitedNotificationListener?

  Yes, except it should be:

public void removeUnsolicitedNotificationListener( LDAPResponseListener listener )

  I was thinking that you could have more than one listener - that's why the method naming (also, of course, to be consistent with the JDK's listener method naming). An implementation could feed each listener with a copy of each incoming unsolicited notification, and each client could pull out notifications independently.

Rob

---

From: Steven Sonntag <[email-masked]>
Date: Tue, 28 Nov 2000 16:38:39 -0700

>   I was thinking that you could have more than one listener - that's why the method naming (also, of course, to be consistent with the JDK's listener method naming). An implementation could feed ea…

Sounds good.

Does there need to be a method on LDAPConnection that is something like

    LDAPResponseListener[] getUnsolicitedNotificationListeners()

to discover which listeners are allowed to receive unsolicited notifications on this connection?

-Steve

---

From: Rob Weltman <[email-masked]>
Date: Tue, 28 Nov 2000 15:49:02 -0800

> to discover which listeners are allowed to receive unsolicited notifications on this connection?

  That is not part of the standard listener pattern in the JDK, and I don't see any production use for it. Only the connection itself cares about what listeners are registered (except for if you are debugging the implementation; if you are debugging a client you can wrap the two methods in a derived class).

Rob

---

From: Steven Sonntag <[email-masked]>
Date: Tue, 28 Nov 2000 16:54:23 -0700

>   That is not part of the standard listener pattern in the JDK, and I don't see any production use for it. Only the connection itself cares about what listeners are registered (except for if you ar…

I was thinking of an application needing to disable the receipt of Unsolicited notifications
for a connection.

---

From: Rob Weltman <[email-masked]>
Date: Tue, 28 Nov 2000 15:57:44 -0800

> I was thinking of an application needing to disable the receipt of Unsolicited notifications

  That can be done by removing the listeners. I don't think it is a big deal for an application to keep track of its listener(s) if it wants to disable listening later on.

Rob