RE: [reSIProcate] dum changes to Invite Sessions

["Derek MacDonald" <derek@xxxxxxxx>]

This requires the app to save state & match dialogs for when the adorn
method is called; if we are going to use this approach I would prefer to
pass in a functor and have DUM hold the state; 

virtual void reject(int code, AdornFunctor...);

I would prefer just exposing send, it's less code for the application.

--Derek

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of david Butcher
> Sent: Wednesday, November 17, 2004 1:19 PM
> To: Jason Fischl
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] dum changes to Invite Sessions
> 
> Quoting Jason Fischl <jason@xxxxxxxxxxxxxx>:
> 
> [snip]
> > Derek and I had a phone call to discuss this issue. We will provide
> > alternate interfaces for:
> >
> > // These 3 are as proposed earlier
> > void provisional(int code);
> > virtual void reject(int code);
> > virtual void accept(int code=200);
> >
> > // Additional interfaces that allow the app to adorn messages and then
> > // send them. It is recommended
> > SipMessage& provisionalAdorn(int code);
> > virtual SipMessage& rejectAdorn(int code);
> > virtual SipMessage& acceptAdorn(int code=200);
> > virtual void send(const SipMessage& msg);
> >
> > Usage would look like this for the adorn versions:
> > ServerInviteSessionHandle handle;
> > SipMessage& rejection = handle->rejectAdorn(482);
> > rejection.header(h_Warnings).push_back(warning);
> > handle->send(rejection);
> >
> > Most applications would just do:
> > ServerInviteSessionHandle handle;
> > handle->reject(482); // would send synchronously
> 
> I prefer not exposing the send method. I propose that the adorn
> functionality is
> provided as immediate callbacks.
> 
> virtual void provisionalAdorn(SipMessage& msg) {}
> virtual void rejectAdort(SipMessage& msg) {}
> virtual void acceptAdorn(SipMessage& msg) {}
> 
> If the app wants, it can override the adorn method(s). The send is called
> from
> dum like this:
> 
> handler->provisionalAdorn(msg);
> send(msg);
> 
> This is a synchrounous interface; the application can marshall whatever
> state it
> needed in the adorn at the time of the provisional/reject/accept call.
> 
> david
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel