[reSIProcate] [DUM] client handlers and user data
Derek, Jason, and david have been kicking these ideas around for a few
days. Now you can kick them around too...
Proposing two changes to DUM. One concerning client handlers and one
concerning application data assciated with usages.
The proposals are independent.
Proposal 1: client handlers
Each of of the client make methods of DialogUsageManager:
makeInviteSession
makeSubscription
makeRefer
makePublication
makeRegistration
makeOutOfDialogRequest
Take, in addition to their current arguments, a required FooHandler
pointer. The application is expected to derive each abstract handler.
This provides the application with a type-safe custom data structure
where they can maintain state associated with a collection of usages.
Usage level callbacks will be to this custom handler, so the application
will have access to their entire context. The application is free to
make this context as rich or simple as it wishes.
DUM currently has parallel methods to create a usage within an existing
dialog. These interfaces would be moved to the corresponding base
handlers, obviating the need to pass DialogIds.
The DUM will destroy the handler when the DialogSet is destroyed.
Proposal 2: usage application data
BaseUsage gets a pointer to polymorphic ClientData instance. ClientData
is derived by the application and given to the usage. The application
can retrieve the client data pointer and dynamic_cast it to their
derived type. Destruction of the ClientData is invoked from DUM through
a virtual destructor. Note that the application can use their derived
client data destructor as a callback for cleaning up application data
structures.
david