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

>>> Rob Weltman <robw@worldspot.com> 03-Jan-01 5:13:40 PM >>>
Steve Sonntag wrote:

>
>
> >>> Rob Weltman <robw@worldspot.com> 27-Dec-00 10:53:27 PM >>>
> Steven Sonntag wrote:
> >
> > 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
>
> 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........................................What you say may be true, but - using the listener paradigm allows thedeveloper to combine any combination of listeners, normal messages,and unsolicited messages. Why make an out of a special out of band APIfor something that could be handled naturally by the existing API. When you say the application wants to know immediately, you meanthe unsolicited notification message should comes up first, i.e. returnedto the application before other normal messages - correct? If the unsolicitednotification is mixed with other messages, the draft should specify thatunsolicited messages are returned first.
> -Steve

No, not at all. With an event listener model, a client that is interested in unsolicited notifications registers as an UnsolicitedNotificationListener. Immediately when an unsolicited notification arrives, a method of the client (e.g. messageReceived) is called with the unsolicited notification as parameter. That way the client is notified immediately and asynchronously rather than having to poll the message queue. Besides being simpler and more convenient for the client, it is much cleaner and less error-prone both for the client and for the implementor of the API. In-band responses are delivered in-band to the submitter of in-band requests; unsolicited notifications are delivered out-of-band to a requestor of unsolicited notifications.

Rob
................................................................