[Easysoap-developers] Non-blocking EasySOAP++

[Frederik R. <fre...@re...>]

Hi,

   I am using EasySOAP++ both as a server and client in a commercial
development (the whole thing is at an early stage but EasySOAP++
seems a good choice and has done well in my proof-of-concept).

One component where I need to use EasySOAP++ is a single-threaded
multiplexed server, where data has to be read and written from/to
network sockets all the time. I cannot afford to halt the whole
operation while waiting for a SOAP response. I need to integrate
EasySOAP++ into my "select" or "poll" infrastructure (which might be
a glib "main loop", not sure yet). 

I guess I'd be capable of doing that myself somehow, but I'd like to
hear your opinions on this because, if done properly, my efforts
could flow back into the project to be used by others in the same
situation.

I would very much like to solve this problem without multi-threading
(for fear of introducing too much complexity) but I'm willing to do
it if it turns out to be the best solution. 

Does anybody have an idea how to best approach my problem? It seems
that I would have to change a *lot* of classes to solve this
elegantly. 

How about this: Create a new "SOAPAsyncProxy" which acts like a
SOAPProxy but, in its "Execute" method, is passed a new
"SOAPAsyncListener" object (usually the caller itself). I would also
need a new SOAPTransport class that is able to communicate with some
kind of central mutliplexing mechanism, e.g. the glib "main loop".
Calling "Execute" would only create the raw XML and schedule it for
sending, then the central "select" mechanism would interact with the
SOAPTransport and associated classes to perform reading and writing,
in multiple steps if required (control of execution passing back and
forth between EasySOAP++ components and the select loop by means of
interfaces/callbacks). When the last byte has been read, the response
is parsed and control is transferred in a call-back to SOAPAsync-
Listener.

Does this sound like something that would fit into the rest of the
EasySOAP++ framework, or rather like an "ugly add-on"? Any better
ideas? Any pitfalls I have overlooked?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail fre...@re...  ##  N49°00.22' E008°24.56'