Perhaps that's what you're used to, but with Perl, I think things are different. You already need to carry a heavy interpreter around, and adding LWP to that doesn't add much to disk space and memory usage. On my box, Perl with HTTP::Daemon takes 5 MB of memory. That is of course more than the 3 MB a bare interpreter is, but it is less than, for example, having Tk loaded (6.5 MB). (Perl + Gtk2 = 14 MB.) And you probably have LWP loaded anyway :)

I think your're totally right there. In my present similar situation at work, if I knew with confidence that even a small percentage of my desktop users had Perl on their machines, I would be all over HTTP::Daemon. As it is, they don't and I'm struggling to find a good alternative.

E-mail was once for client side MUAs, but sites like Hotmail and Gmail have rapidly changed that.

I agree with this as well. I think Gmail is a real slap in the face to people who say "the web browser as GUI is dead, it has passed the limit of its potential, let's just wait for XAML or XUL or whatever's next" and it has inspired me to start doing more creative things in my dynamic HTML work. I'm just saying the obvious candidates are those things that are similar to what you'd typically see in a web site.

Then how do you shut down if the more tech savvy user hits a hotkey to close the browser, or even kill the browser? Or if the browser crashes, or if the user surfed to another site?

To my knowledge, body.onunload is the only portable way to do that. Other approaches are browser specific. For example, if your browser is MSIE on Win32, then you can launch it with something like (untested):

my $browser = Win32::OLE->new('ShDocVw.InternetExplorer');
$browser->{Visible} = 1;
$browser->Navigate("http://localhost:$port/someurl");
[download]

and then periodically query the $browser object to make sure it's still there (I forget how exactly but the MSDN site has all the docs).