[reSIProcate] RE: dum/resip design meeting
Quoting Scott Godin <slgodin@xxxxxxxxxxxx>:
(jumping from private to public -- hope that's ok)
> Oops - I missed it - I didn't get this until after the call. : )
>
> But I am very interested in any direction that DUM is taking! Did the call
> happen? Can anyone make a quick summary for me?
I was charged with the write up task (below). Some of this is what we talked
about, some of this is blatant editorial, some of it is design mumbling.
Nothing writ in stone yet.
david
>>>>
Quick Summary:
Collapse Handle, Handler, and Usage into one class.
Interface will move from DUM, *Handler, *Usage to base class usage of
appropriate type.
Application will derive from usage type to add type-safe application
data. All callbacks are through virtual methods on the derived
application usage.
Advantages:
- unify application callbacks and application data
- get rid of handles
- get rid of castes
Disadvatages:
- assumes a single thread model (may be generalizable with work)
- not even sort of backwards compatible
- even harder to wrap in C?
- requires a reference counting smart pointer
Not Quick Summary:
UAC side
========
No possibility of forking
-------------------------
E.g. MyRegistration inherits from dum::Registration.
App creates an instance foo of Sptr<MyRegistration> against the dum
and whatever application data it would like to keep with the
invitation. If it likes, app can call getMessage() and decorate. App
calls foo->send() to start the registration.
Callbacks occur directly on the foo instance as virtuals (in its role
as a handler).
The app may or may not keep track of foo. At any time, it may drop its
reference to foo. Should there be a way to indicate that the instance
is no longer interested in callbacks?
Dum calls virtual dispose() on the instance and drops it from its own
datastructures.
Possible forking
----------------
Non-forking:
While forking is a possibility, the application does not want to deal
with multiple forks. This is likely the case for most client invites.
E.g. MyInvitiation inherits from dum::ClientInvitation.
The application creates foo, a Sptr<MyInvitation> against dum and
whatever application data it would like to keep with the
invitation. As above, the invitation supports getMessage() and send().
All callbacks are on the MyInvitation instance directly as virtuals
(in its role as a handler).
DUM is reponsible for ensuring that at most one fork is delivered to
the application. All other forks are quietly terminated by DUM.
Forking:
The application wants to deal with multiple forks. This is likely in
some subscription event packages and possible for INVITE.
E.g. MyInvitation inherits from dum::ForkingClientInvitation<MyInvitationUsage>
(aagh -- an application exposed template -- alert the media! why, you
ask? so the forking application class can collect the application
forks type safely. we discussed making the collector and fork classes
the same but I changed my mind; this scheme requires the app to define
two classes, but is conceptually much cleaner)
MyInvitateUsage inherits from dum::ClientInvitationUsage.
The application creates foo, a Sptr<MyInvitation> against dum and
whatever application data it would like to keep with the invitation.
MyInvitation implements (is pure virtual in parent):
Sptr<MyInvitationUsage> createUsage().
This method is called for each fork created. The application is free
to store and manipulate these usages.
Callbacks occur on the created instances of MyInvitationUsage as
virtuals in their roles as handlers.
UAS side
========
In general, multiple usages within a server side dialog will not be
supported. (RjS contends that the error recovery issues are fierce and
that there are safer mechanisms to address the targeted message
requirement; see draft-sparks-sipping-dialogusage) some specific
machinery for refer will still be supported.
DUM will handle multiple dialogs within a usage to the extent that
attmepting to create additional dialogs will fail gracefully.
Factory methods on dum
----------------------
return type of factory method is Sptr of appropriate server usage base
- by method
Sptr<ServerRegistration> createServerRegistration(const SipMessage&);
...
- by event type for SUBSCRIBE
void addSubscriptionFactory(const Data& event, Sptr<ServerRegistration>
createServerRegistration(const SipMessage&);
- allow override of bySubscribe (calls dynamic factories by default)
Message is passed to factory method.
Application may store Sptr<>ed instance in own datastructures.
(registering method factories will make determining the handled methods
easier. on the other hand, would be nice if this was determined at
compile time. asking dum what methods it supports is a bit awkward
if the app does stuff during the factory calls)
Threading
=========
Propose to start with a single threaded model. The design can be
generalized to multiple threads by 1. using a thread safe shared
pointer 2. replacing direct calls to dum with a memento/fifo
model. Note that we are making sure that the dum thread is safe to use
with a single application thread, not that that usage is safe to use
with multiple application threads -- that is still the apps issue.
<<<<