Re: draft Java-api-12

[Steven Sonntag <vtag@novell.com>]

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

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
Novell, Inc., the leading provider of Net services software