[reSIProcate] DUM v. 2 proposal (early draft; server)

[Jay Hogg]

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 at list.sipfoundry.org
>https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>  
>