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