in reply to Re: Re: Re: Stunnix Perl Web Server - a platform for portable browser-based applications
in thread Stunnix Perl Web Server - a platform for portable browser-based applications

Ours doesn't have any dependencies on non-standard modules. But if you'll follow HTTP::Daemon path, the total size of modules required from libwww will be much more than 200kb. Yes, it's not a rocket-science, but a lot of efforts are needed to support non-blocked unbuffered IO and supporting simultaneous http requests to dynamic content on all platforms.
  • Comment on Re: Re: Re: Re: Stunnix Perl Web Server - a platform for portable browser-based applications

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Stunnix Perl Web Server - a platform for portable browser-based applications
by diotalevi (Canon) on May 22, 2004 at 21:47 UTC
    Say, purely from a "if I were to do this", isn't that just the sort of thing POE would be good for? I mean, I wrote a TCP socket server (for streaming chatterbox) in just a few lines.
      In my code, the network handling routines were pretty small. And I used shared hashes for passing paramters and data (but I could serialise them so an application's state would persist across restarts of the server - oh for first-class closures).

      POE would work as well as any other server daemon. It's a matter of what you're comfortable with.

      Having played with writing a fair bit of GUI stuff, I've found that most of the work is in stupid, boring bookeeping - implementing Widget::Button, Widget::RadioButton, Widget::CheckButton, etc.

      Even with OO and using inheritence and eval tricks, it's still repetitive.

      ____________________
      Jeremy
      I didn't believe in evil until I dated it.

      POE is bad for several reasons:
      • It's huge and requires too many additional modules.
      • It doesn't work on perl-5.004.
      • It's rather slow. Ours transfers static pages 2 times faster.
      • It doesn't have framework for handling several http requests to dynamic content simultaneously (entire slave/master framework would have to be written to support it).
      In fact, implementing functionality we would need from POE (effectively - nice wrapper for select(2) with callbacks) is about 6% of all code size of SPWS.