Juha Heinanen wrote:
Stefan Sayer writes:
> but then the xmlrpc call would have to wait until final response (or
> timeout) of the request, which would not be desirable.
you are correct. getting final reply to invite could last tens of
seconds. but what would the problem be, because openser process needs
to wait for the transaction to end anyway?
- you could not react on non-final responses in you application that
uses t_uac_dgl over XMLRPC
- your application, or at least the calling thread, is blocked until FR
- xmlrpc call state would have to be saved together with transaction
state (with list of replies etc) in shared mem, because another process
could handle the response to the transaction and when FR is received
XMLRPC reply needs to be sent
mapping asynchronous reply on syncronous request/reply seems to me not a
good idea generally, I think it unnecessary complicates things.
Stefan
-- juha
--
Stefan Sayer
Media Services Development
iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany
[EMAIL PROTECTED]
www.iptego.de
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
