Re: [reSIProcate] DUM v. 2 proposal (early draft; server)
David,
I like getting rid of the factory stuff and I think I like what you are
proposing
on the changes. I have 1 "big" question so far:
How do these changes play when an INVITE is sent and you are waiting for
a response?
My background is 20yrs of traditional telephone and the concept of
"making a call" but
not having a controlling point until the other end responds took a lot
of getting used
to (I do fully understand why).
The factory methods work well in this scenario - will the virtual call
back have
visibility to the AppDialogSet to be able to handle association back to and
originating request?
Today I use a derived AppDialogSet to contain the mapping between the
dialog callback
Client::onNewSession and the requestor - will AppDialogSet(derived) be
via a virtual
method also? Passed on a send() for a client INVITE? Subject to
auto_ptr<> so it doesn't
go away until the application side has also disposed of it?
I'm thinking through this in the concept of hundreds of concurrent
DialogSets in
existance with possible hundreds of outstanding client invites.
I've got another email started from your first with questions/comments
but this open
a lot of new ones that now affect my questions ;)
Jay
david Butcher wrote:
Hi all,
(more DUM v. 2)
My proposal for the server side is to abandon the factory idea. Instead, there
are virtual methods on DUM for each server type where the request is passed. The
server application, like the client side, creates an instance of the derived
server usage with an abitrary constructor. Again, a manage() method is used to
pass the usage to DUM and a DUMPtr is returned. This version of manage takes the
incoming message as an argument in addition to the auto_ptr'd instance and
optional fifo. After calling manage, the application asks the DUMPtr-wrapped
instance to accept or reject or whatever.
There is the question of what to do if the application doesn't manage the
request at all.
This same approach can be used to handle forking and in-dialog requests. Each
fork causes a virtual callback on the application client instance and the client
decides how to manage the message (e.g. 180). In this case, the manage method is
invoked on the application instance rather than the DUM but again with the
auto_ptr'd new instance, and the message.
In dialog-requests are the same; the usage that set up the dialog gets the
callback and hosts the manage() call.
david
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel