Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: GUI with HTTP::Daemon

by Errto (Vicar)
on Dec 18, 2004 at 21:51 UTC ( #415911=note: print w/replies, xml ) Need Help??


in reply to GUI with HTTP::Daemon

I'll tackle the meditative part first. For a long while I thought that desktop web applications were utterly pointless, because a) the GUI is there anyway, and b) 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)). Then I saw the Google Desktop Search and that changed my opinion. So now my answer is "if it's the sort of thing that would make sense in a normal web app, it makes sense as a desktop web app."

For the SOPW, I usually prefer not to do it that way. I once tried capturing the body.onunload event in Javascript but I couldn't make it work reliably. 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().

Replies are listed 'Best First'.
Re^2: GUI with HTTP::Daemon
by Juerd (Abbot) on Dec 18, 2004 at 22:34 UTC

    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' }

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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://415911]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (15)
As of 2019-03-21 15:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How do you Carpe diem?





    Results (109 votes). Check out past polls.

    Notices?