So I suppose I should chime in since my one huge Perl project at the moment is a desktop app that works precisely this way. I got my inspiration for it from the node GUI with HTTP::Daemon and I have to say that while I was poking at it the one thing that struck me was, wouldn't it be good if there were an API for this. Tomorrow when I get in I will see how well this API matches my program structure and hopefully that will give me the basis for a more useful reply.

Regarding threads, I've played with threads once or twice during the lifetime of this particular project, and so far the benefit isn't really hitting me. The only clean way I can think of to use threads is to simply start off by spawning two threads, one to handle the HTTP::Daemon loop and one to do any work not directly related to generating the response. I don't think spawning a thread for each request will be good because it's too much overhead.

In terms of security, the most important thing is that you listen only on localhost, which you're already doing. You could also try generating a magic key to go into the query string like Google Desktop does, but I have not yet figured out what the security benefit of that is.

And don't forget, this may be cross-platform but an application developer still has to deal with the issue of users actually having Perl. For applications, you might want to use PAR to package executables for the platforms the app needs to run on.