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

[david Butcher <david@xxxxxxxxxxxxxx>]

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