|
>>> 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
the
developer to combine any combination of listeners, normal messages,
and unsolicited messages. Why make an out of a special out of band
API
for something that could be handled naturally by the existing API.
When you say the application wants to know immediately, you mean
the unsolicited notification message should comes up first, i.e.
returned
to the application before other normal messages - correct? If the
unsolicited
notification is mixed with other messages, the draft should specify
that
unsolicited messages are returned first.
-Steve
-Steve
|