Practical Internet Groupware

dhttp in the Windows Environment

If you buy into the notion that dhttp is a service that can usefully enable groupware development, and your target group is—as most are—Windows based, you’ll want a more elegant way to run dhttp than by launching Perl from the command line at system start-up. One way to hide the dhttp process from the user is to use the Windows Scripting Host (WSH). For example, if you rename the main dhttp driver from dhttp to dhttp.pls, then you can run it like this:

dhttp.pls

In this mode, there’s no command console. Instead WSH runs dhttp, thanks to the PerlScript layer that enables ActivePerl to plug into WSH. If you package the previous command into a .CMD file and refer to that file from the Windows start-up folder, dhttp will start silently when Windows starts. Of course, it will run silently too. Messages that went to the default error channel, STDERR, won’t appear, so you’ll need to log them or—when you want them to appear to an interactive user—convert statements that print to STDERR into statements that use the WScript->echo( ) method.

The real problem here is system shutdown. The dhttp server spends nearly all its time blocked on an accept( ) call, waiting for the next incoming connection. As a result, the process that runs dhttp can’t react to Windows messages. When Windows tries to tell that process that it wants to shut down, there’s no response. Windows then invites the user to forcibly terminate the process—and that’s hardly the desired effect.