Re: [reSIProcate] RE: dum/resip design meeting
Hi, all,
I think it is better to release a new version before
starting these changes. Otherwise, the users will get
a feeling that there is no stable version of DUM.
Jason, when the new version get released? Thanks,
kaiduan
--- david Butcher <david@xxxxxxxxxxxxxx> wrote:
> 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
=== message truncated ===
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca