On Mon, 2002-04-22 at 21:41, Rocco Caputo wrote: > On Thu, Apr 18, 2002 at 05:01:44PM -0400, Peter Chen wrote: > This may be fine depending on what handle($input) does. I wouldn't > worry about breaking up handle() if it's quick, for instance.
This thread actually ties into the other thread about PoCoCl::UserAgent. :-) In my case, most SOAP requests can be handled quickly, returning values of variables, etc. I have made them synchronous calls using $poe_kernel->call(). However, there are a couple instances where it needs to make a https connection to retrieve some data. This is where PoCoCl::UserAgent comes into the picture. Since the SOAP clients are CGI's that display returned information, to improve the responsiveness, I decided to circumvent the issue by returning a fault code right away indicating that the client should check back again, while an https connection would be initiated by the SOAP server. Combining this with client pull (using "refresh"), the result was reasonable. > However, since SOAP works over HTTP, I'm led to believe that it's a > synchronous RPC protocol. Yes, and this is where I find a steep learning curve, how to reframe the synchronous procedural programming that I was used to in an asynchronous event driven environment. > The application seems to lend itself to > either the first or third solution (blocking handle() or forking). I am beginning to notice that there are more and more cases, where forking is necessary. For example, if I want to play it safe, I would probably fork and make the https connection using LWP, so I don't have to worry about it blocking other POE processing. Of course, all the time, Java folks would probably use threads w/o even thinking twice, *sigh*. Thanks for your response. It was helpful. Pete
