Java and Perl (was Re: [plug] Time & Task Management Tool)

Trevor Phillips phillips at central.murdoch.edu.au
Fri Jun 4 07:15:05 WST 1999


Bret Busby wrote:
> 
> Also, from what I understand (courtesy of Data Comms security
> lectures), a threat comes from "mobile code", that appears to be what
> java applets are. I may be completely wrong in my understanding, but
> the rule appears to be, better safe than sorry. Thus, also, I avoid
> the use of java, in browsers.

There is a threat from such apps. Fortunately, Java is by Sun, and they
were very heavy on the security. Unfortunately, Micro$oft had a dabble
at their own, and threw half the security out the window (but I believe
it's better now). The example I heard went along the lines of Java
operates in its own li'l environment, including memory-space, and that's
all it has access to, but one of Microsoft's earlier implementations
didn't have such bounds, so a Java applet had complete access to the
entire system memory!

Another concern is what is the applet doing?? When Java first came out,
a colleague suggested we use it for distributed processing. Based on a
similar concept to the SETI @ Home, every page on a site would in its
footer contain a tiny Java applet (or one that did something basic), but
the inner workings of that applet could use the client's CPU to do
processing!!

So, you could have thousands of people contributing to the processing of
important stuff, like, oh, MP3 encoding?? Password decryption?? You get
the idea... ^_^

> The extent of the limiting, is probably better demonstrated, by
> referring to the ANZ Internet banking site, which uses javascript
> heavily, and can only be fully used, by running IE4 or IE5, according
> to the ANZ staff. MacOS, Linux, and any OS apart from M$windows, is
> not supported by that facility. IE is the only browser that can
> reliably use the facility.

This is an example of javascript dependency. I use JS myself, to a small
degree to enhance a page, but I try to always make it work without JS,
be it via an alternate page/method, or through repeating the processing
in the CGI later (in the case of Form Validation).

> That leaves Perl, as the only viable option, from the options that you
> have mentioned.

I use Perl generating HTML pages. Sometimes that includes some JS.

> From what you have thus far said, in this matter, it appears  that
> Perl works at the server end, and requires a Perl enabled server.

> This sounds a bit like php

Not quite. Writing a Perl app requires Perl on the server machine. It
doesn't require native support from the Webserver, like PHP does.
Getting the MOST out of a Perl app does mean going towards FastCGI (Perl
apps stay resident to negate the initial load-time of the script) or
mod_perl (Embedding a Perl interpreter into Apache, allowing complete
Webserver customisation through Perl scripts).

> Leon could advise you as to how php could best be applied in this
> context,and whether php or Perl would be better suited, than I could.

I've used php before. One of my first introductions to the Web was
having to maintain a PHP server for someone.

> However, from memory, php has the ODBC facility, and I do not know
> whether Perl does.

Perl can talk to most SQL databases, thanks to the DBD/DBI stuff. (The
DBD gives a common library for using databases, and then there's a
separate DBI translating that into Db specific calls. Means I can write
code for mysql, then get it running with Oracle with minimal hassles,
for example.)

Again, personally I prefer Perl. ^_^
As I mentioned in a previous email, my coding style is towards one app
(pulling in required libraries), with chunks of HTML in it, rather than
HTML pages with chunks of code in it.

> From what I understand, including from what Anne has said, it could
> probably have been created and implemented, in less time than the
> debate has thus far taken (about an hour or so, depending on the php
> or Perl skills, and the database skills for the back end), depending
> on the requirements specification.

^_^
If it was so easy, why has no-one done a comprehensive one yet??
There was a detailed fault-tracking system written in PHP (can't
remember the name off the top of my head), which is still under
development, and isn't all there IMHO. The sort of tool we would need is
more complex than that.

Although from discussing design specs with my colleagues, we're leaning
towards a solution that is in fact rather simple and downright
versatile! ^_^

-- 
. Trevor Phillips             -           http://jurai.murdoch.edu.au/ . 
: CWIS Technical Officer         -           T.Phillips at murdoch.edu.au : 
| IT Services                       -               Murdoch University | 
 >------------------- Member of the #SAS# & #CFC# --------------------<
| On nights such as this, evil deeds are done. And good deeds, of     /
| course. But mostly evil, on the whole.                             /
 \      -- (Terry Pratchett, Wyrd Sisters)                          /


More information about the plug mailing list