in reply to Re: GUI with HTTP::Daemon
in thread GUI with HTTP::Daemon

the GUI is there anyway

Is it? It may be in Windows, but X has no widgets (controls) of its own. It doesn't even manage windows itself. In X, you need a toolkit in order to easily program GUI applications. There are many toolkits, and it's hard to pick one. It's even harder to pick one with portability in mind. On the other hand, almost every platform has a browser, and they're all compliant enough to program a coherent application in.

embedded HTTP daemons cost so much in overhead (for example, I started playing with embedded Tomcat recently; cool concept but enormous RAM hog and a 10MB installation (which is a lot if you're offering something for download)).

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 :)

if it's the sort of thing that would make sense in a normal web app, it makes sense as a desktop web app

That's still not a clear line you draw. When does something make sense in a web application? E-mail was once for client side MUAs, but sites like Hotmail and Gmail have rapidly changed that.

So instead I have a big link or button on the page that says "Close Me" and that button calls a Javascript function which first sends a ping back to the server (using IFRAME or XmlHttpRequest) with a URL that indicates the client is exiting and then calls window.close().

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?

Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }