Wrt HTTP::Daemon. That is interesting, but it puts me back into a similar position as the original problem -- now I will have to have my script with HTTP::Daemon running separately. I have grokked its notes, but I would have to see some working examples to fully understand its capabilities.

Unless, of course, I build the web server daemon right into my original script (the one I want to convert to a service). The web server daemon could fork a process that would run the portion of the script that deals with the email server and the db server, and the web server would itself be available to further control and monitor the above actions.

Drats, this is getting to be more complicated that I thought.

Reading your concerns on HTTP::Daemon, and paulbort's reaction, I had a thought - your requirements are pretty basic - to be able to communicate state/status information from a service to the outside world. It occurred to me that this is essentially a one-way communication. If security is not an issue, I think the simplest solution would be to have the service periodically pump out UDP packets containing state information. If there is a program listening, it can read, format, and display the information, otherwise, the info gets thrown away. This could be implemented with a simple UPD socket writer.

If you need more sophesticated Controls (bi-directional communication), and did not want to fork, you could try Net::Server::NonBlocking.

    ...each is assigned his own private delusion but he cannot see the baggage on his own back.

I too started off (this thread) by thinking that my requirements were basic. Now I am thinking that perhaps they are not.

If I were to provide an example of what I want, I would point to the little control thingy for Apache that sits in the Windows system-tray. You can start, stop, restart the Apache service. You can't config Apache through this (you can't config Apache any way other than editing the httpd.conf file by hand anyway) but this is the closest I can think of as an example of what I want to accomplish.

Except, I would like to use a web-based interface for my own program to do what this Apache thingy does instead of a native Win doohickey.

I would also like to use the web interface to modify some of the conf params. This portion seems easy -- I can use Config::Simple or some such, or just open up a conf file, tie the values to a hash, and display them in an html form that can then be used to modify and save the conf file back out again.

What I can't grasp is how to control a non-web, continuously running program via a web interface.

Why do I want a web interface? Simply because the web is about as cross-platform an interface technology as one can get. My current program is just a simple Perl script that is launched from the command line, and it runs until Ctrl-C or until it die-s because of some boo-boo. I am thinking of evolving this to something that can be controlled by another program (my web interface), can be eventually cross-platform -- it is right now running on Windows, hence, my evolution to a Win service, but there is no reason why it couldn't run on a *nix box.

I am answering paulbort and Tachyon's comments right here -- I don't have to read the params everytime the script wakes up. It just reads them when it launches until it dies, much like what Apache does. I certainly do not want to muck around with Win registry -- shudder.