converting a command-line program to one with a "pretty" interface

[punkish]

A few months back I wrote a command-line program running on a Win box with ActiveState's perl that does the following --

1. it runs in a "while (1) {}" loop forever, with a "sleep 300" in it until ctrl-c-ed;
2. every 5 mins the program queries an email account on an Exchange Server and checks for messages;
3. if any messages are found, it extracts certain information from those messages using regexp;
4. the extracted information is inserted in various tables in a SQL Server db;
5. new emails are created based on the extracted information, forwarded to certain addresses;
6. the messages are moved to another mail folder for archiving, and a log is written out.

I used Mail::IMAPClient, Mail::Sendmail, HTML::Parser, and DBI.

I am now ready to write the next version of my program, and, thus, I seek the following advice (I will be re-writing my code as a more OO code -- I've recently been learning OO techniques, and I believe this program could benefit from such an approach) --

Should I use the new Email::Simple modules instead of the above-mentioned Mail modules (I found the Mail modules to be a bit complicated, and somewhat unreliable in conjunction with Exchange Server)?

And, more imporantly, how could I go about converting my program to give a more sophisticated "appearance"? In particular, I would like to convert the program so that it runs as a Windows service (I tried doing that, and while I was able to create a service, the darn thing never ran) or a *nix daemon; and I would like to provide an interface to start, stop, and minimally configure the program (like, provide the sleep time, email account and email server names and passwords, view log files, etc.). A web-interface would be great because it could be controlled from anywhere, and would be platform-independent.

All advice will be much appreciated.

Update: its the "interface" part that I am most eager to implement in this new version -- some easy, clickety-click way to allow the "admin" of this program to set config params, start and stop, and load and read the log files.

[tachyon]

With a program that sleeps for N units of time and then does stuff the obvious solution would be to make it read a config file as soon as it wakes up, then the bulk of the interface just edits this file. On *nix you could use a HUP signal to make the daemon re-read the config file. $SIG{HUP} = \&read_config;

[punkish]

thanks for the advice. The config file is read only at start-up time -- it contains the various email addresses and db params. Once the program gets going, the only interaction with the user would be to display the status (perhaps by showing the log file of what has been done) or let the user stop/restart the program.

[NetWallah]

I have used, and recommend the NT resource kit tool "srvany.exe" to run perl scripts as services. This can be used in conjunction with "instsrv", Service Installation Wizard (Srvinstw.exe), or "sc.exe" to configure and start the service. There are also third party tools like FireDaemon (which now wants $$$) to do this.

For the UI, I suggest making your service (or pseudo-service) a web server using the simple HTTP::Daemon module, perhaps on a different port, in case you run a web service on the same server.

[punkish]

Thanks for the advice on srvany.exe. I used something else (I forget now) and, as I stated above, was able to convert my script to a service, but it did not run. I will try srvany.

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.

[NetWallah]

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.

[paulbort]

I'd like to second tachyon's suggestion of using a second program for the configuration and re-reading the config when the program wakes up. If you're trying to stay with the Windows way, the right place to store the settings is in the registry, probably under HKEY_LOCAL_COMPUTER\Software\YourCompany\YourApp\Settings.

Then you can change your service to use those settings, and write a separate Perl/Tk front-end program to change the settings (and control the service) without breaking the already-working code.

I think that adding HTTP::Daemon to the mix is more complicated than you need for a few parametes, unless of course you're already comfortable with it. The Widget demos in ActiveState should get you 75% of the way to a Tk-based settings screen.

Regarding changing the E-mail modules you are using, or switching to OO-style: If it ain't broke, don't fix it.

[bl0rf]

Hello!
I don't know much about Tk ( seems to be more than the average programmer though :-), here is a mighty ugly demo program which will get you on the way. Forking should work...although it doesn't on my windows computer...

use Tk;

$SIG{ CHLD } = sub{ wait }; 

my $top = new MainWindow;

$top->Label(-text => 'Welcome to My Mail Program')->pack;
$top->Button(-text => 'Start',
                      -command => \&myStartRoutine
                      )->pack;

$top->Button(-text => 'Stop',
                      -command => sub{ kill($pid); exit; }
                      )->pack;

$top->Label(-text => 'Enter server name')->pack;
my $servname = $top->Entry(-width => 10);
$servname->pack;

$top->Button(-text => 'Configure',
                      -command => sub{ print "The server name is: ",$s
+ervname->get() ,"\n"}
                      )->pack;

MainLoop;

sub myStartRoutine
{

if( !($pid = fork) )    # child has the main loop looping for ever
{
   while( 1 )
   {
      print "program started\n"; sleep( 1 );
   }
}


}

Hope this helps!