|
This makes more sense to me now. Although both
mechanisms work,
the callback paradigm has the advantage of immediate
notification to the
application. Thanks for the clarification. I think
this is a better way to go.
I also believe we should add Kurt's suggestion, that requests
should
not use message ID of 0 - i.e. let it be reserved for
unsolicited notifications.
-Steve
>>> Rob Weltman <robw@worldspot.com> 05-Jan-01 9:36:04 AM >>> Steve Sonntag wrote: > > > >>> 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 > ................................................................ You are describing a callback mechanism, but the interface describedin earlier e-mails, just registered an LDAPResponseListener which hasno callback semantics associated with it. Are you thinking of a newkind of listener. In our previous discussion you suggested the following API > > public LDAPResponseListener addUnsolicitedNotificationListener( > > > LDAPResponseListener listener ) > > > > > > public void removeUnsolicitedNotificationListener( > > > LDAPResponseListener listener ) Are you thinking of adding a method to LDAPResponseListener toregister a callback method? -Steve > It might be better to define a new interface for the callback. public void addUnsolicitedNotificationListener( LDAPUnsolicitedNotificationListener listener ) public void removeUnsolicitedNotificationListener( LDAPUnsolicitedNotificationListener listener ) public interface LDAPUnsolicitedNotificationListener { public void messageReceived( LDAPMessage msg ); } Rob |