|
Yes, it sounds like that what it implies - the API
never
initiates a message with message ID of 0.
If an application performs an extended operation
with messageID 0, is it allways possible for the API
to distinguish responses to the extended operation
from unsolicited notifications?
-Steve
>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 21-Dec-00 1:57:01
PM >>>
At 01:30 PM 12/21/00 -0700, 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? Is there a API requirement that requests are not generated with message id 0 (as allowed within the protocol)? Kurt |