On Wed, 2009-09-16 at 10:04 -0400, Beeton, Carolyn (CAR:9D60) wrote: > The application might not be ready to produce a response in-line in the > callback (in the SAA case, a message is posted and handled > asynchronously). However, the application can commit to sending a > response. Therefore I propose to convert the SSC::NotifyEventCallback > to return a boolean indicating whether the SSC should send the response > or the app will. All existing users except the SAA will return true in > their notifyCallbacks. The SAA will return false and MUST then respond > to the NOTIFY (since it is provided with the entire notifyRequest in the > callback, it has all the info it needs to reply)
[As Carolyn and I have just discussed in person:] If we could always be sure that the callback was prepared to generate a response (if it wished to take on the responsibility), then I think that architectural beauty would put the balance in favor of a subclassing approach. But SAA, as is common in sipXecs components, uses a queue-and-process asynchronous approach, so subclassing could do little more than suppressing the generation and sending of a 200 by S.S.C. So the simplicity of the "boolean return from the callback" approach wins the battle. (IMHO) Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
