[reSIProcate] RE: dum/resip design meeting

[andrea]

Hi all,

a note by a resiprocate user... I think that a new version will be help 
but I think the most important point is to design a stable interface and 
implement them in several stable new releases.

Now, I'm working on DUM and I understand today that probably in 2-4 
month I've to change again my apps to use up-to-date resiprocate stack.
I think a new interface (with several docs and samples) will help a 
lot... but if it will be always the same (with only minor changes)!

thanks for your attention!

andrea

kaiduan xie wrote:
> 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 at purplecomm.com> wrote: 
> 
>>Quoting Scott Godin <slgodin at icescape.com>:
>>
>>(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
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> 
> 
>