Re: [LHA-misc] Web interface ...

[John <jk...@pr...>]

On Sat, 26 May 2001, Mike Baptiste wrote:

> I've been a Perl fanatic/programmer for a LONG time an normally would 
> agree to go with Perl.  However PHP is an excellent langauge for web 
> based interfaces to data of all kinds - it has all sorts of cool 
> features including automatic session tracking, etc.

I've been a PHP proponent for about a year.  It will handle 99% of what I
need CGI scripts to do.  This is important because my webhoster (like many
out there) offers PHP by default, albeit somewhat castrated.  Mine also
allows CGI's but requires them to be reviewed prior to release.  PHP is
the path of least resistance.

> The propblem is, 
> PHP is not installed by default like perl is, but there are generally 
> binary packages available for easy install. 

On many Linux distributions PHP is just one additional package
install.  Due to the relaxed US crypto policy, mod_ssl is also 'just one
additional package install'.

> As for cross platform - 
> well, just because a language is cross platform, doesn't mean your app 
> will be :)  It still will need to be ported.

PHP works on Unix, Win32 and MacOS.  Beyond that, well, I suspect you know
what you're doing and can perform the port yourself :)

> So use what works best for you.  Perl is an awesome language and the 
> wealth of CPAN modules available is staggering, but PHP also has strong 
> points - especially from web interface perspective.

Yes there are certain tasks that PHP is not suited for and its base
install is far too thin for my taste.  Unfortunately the Linux
distributions seem to be heading towards only aggregating Base+MySQL.

> Now regarding Java and Javascript - avoid them like the plague ...

I agree with avoiding Java, but you can be fairly sure that most people
will be running with Javascript on, otherwise most sites on the 'Net will
either refuse to work or will work badly.

The Javascript in the popular browsers are fairly close to one another,
one just needs to detect and handle the special cases.  NS4.x is the worst
of the bunch but still (marginally) useable.


When developing a web based interface you must realize that it is
COMMAND-RESPONSE only.  One of the tricks I use is to set up an invisible
frame or layer that is set up to poll (via refresh) a CGI that emits UI
events (alerts, state changes, etc.) and from that frame/layer update the
visible components.

The other pitfall is that due to the multi-process nature of Apache, you
can never be sure which daemon will handle your request.  Therefore, if
your backend depends on a stateful connection (eg. IMAP) the CGI needs to
be a thin layer that communicates with a persistant pseudo-client.

If you still wish to go the Java route, look at my tattler applet.  That
allows a separate daemon on the webserver (only) to send short messages to
your browser without the browser needing to poll.

http://www.projectplasma.com/tattler/