I spent some time this weekend going through SOAP::Lite bugs, and I am so impressed with the S::L developer community! Almost all of the bugs contain patches of some kind. I can't tell you how wonderful it is (as the developer on a project like this) to have your users essentially doing your job for you! So thank you.
But that is not the point of this post. In one of the bugs a user, Michael Douglass to be exact, submitted what appears to be an improved implementation of SOAP::Transport::HTTP::Daemon. I am not ready to include the code in 0.65, but thought I would share it with the community and see if I can't get it to endorse it somehow so that I might include it in a later release.
I will test it eventually, but I am focusing on 0.65_3 right now and don't have the bandwidth for new features like this. Furthermore, I tend to avoid writing an HTTP daemon in Perl when I can use Apache for free. I would be curious to know why so many SOAP::Lite developers like using their own home grown HTTP daemon when there are so many good free ones available. Anyone care to shed some light on this?
> I would be curious to know why so many SOAP::Lite developers like using their own home grown HTTP daemon when there are so many good free ones available...
Simple answer: A separate web server is yet another application to install, configure, track and maintain on my network.
I'm planning on using SOAP to expose the functionality of my log analysis scripts to other applications on my employer's network. By using a built-in daemon I can distrubute the scripts to my logging servers without having to worry about the dependencies and configurations.
Of course, this may be a moot point if the server in question is *supposed* to be a web server!
Posted by: Steve Scaffidi | July 10, 2005 at 07:20 PM
In tight spots like network appliances and embedded systems, a tiny daemon works better.
Posted by: Medi Montaseri | January 25, 2007 at 02:59 PM