http://www.perlmonks.org?node_id=415915


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 => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Replies are listed 'Best First'.
Re^3: GUI with HTTP::Daemon
by Errto (Vicar) on Dec 19, 2004 at 17:11 UTC
    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");
    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).