On Wed, Feb 17, 1999 at 09:51:51AM +0100, Chris Huebsch wrote:
> The first is a "non-java-at-all" Server. It has to create a new process
> when a request arives. Where? The system is almost at the limit? It is
NO.
I keep saying this and apparently nobody is listening.
Let me give you URLs then:
http://www.apache.org/related_projects.html#modperl
"With mod_perl it is possible to write Apache modules entirely in Perl.
In addition, the PERSISTENT interpreter embedded in the server avoids
the overhead of starting an external interpreter and the penalty of
Perl start-up time." (emphasis mine)
http://fastcgi.idle.com/fcgi-devkit-2.1/doc/fastcgi-whitepaper/fastcgi.htm
"FastCGI processes are persistent: after finishing a request, they wait
for a new request instead of exiting."
"FastCGI . . . multiplexes the environment information . . . [allowing]
FastCGI programs to run on remote machines"
> > I do not, and have never, reccommended PHP3 for anything "serious", for just
> > these issues, and others. But mod_perl and FastCGI are quite good for CGI.
>
> Database-Access with php or perl may be simple with simple problems. But
> when the problem gets more complex the problems increase exponentially.
> For instance you change your database from oracle to informix. With php
> you may change all your pages and replace oracle_db_XXX() to
> informix_db_YYY(). In java you write a factory which creates the
> SQL-Statements and only change the factory. The remaining parts of your
> application/applet/servlet remain untouched
Perl has DBI, which is largely JDBC-like. DBI is not quite as good as JDBC
for some things, but it is better for others. DBI creates an abstraction
between the program and the database driver just as JDBC does.
> Java is not just a language! It is an very large API and a Virtual
> Machine too.
> And one usefull use of Applets: I wouldn't do my online-banking with
> ActiveAEKS or just SSL. A-X wouldn't run on a Sparc ;)
Hehe :-)
> There are some problems which require not much data-transfer but a lot
> of graphical work. I cannot imagine transferring every single screen via
> X-protocol. (Embedded X is a X-Server inside the browser - isn't it?)
Essentially yes. Which is the reason for my comment that, even with X
protocol compression, it's probably not good for much other than a LAN, and
even there it suffers from the same problems that Java does.
My point is that applets and embedded X are answers to a question that
nobody asked :-)
I know that Java is a VM, bytecode, etc. What I'm trying to say is that
this is irrelevant -- HTML and the Web are simply the wrong paradigm for
trying to deploy full-fledged applications.
> > I have never disagreed that a Java-based GUI application (note, not applet)
> > as a client would be good, and in fact, in the message to which you are
> > replying, you snipped the part where I said so.
>
> As already written - why to risk serious trouble by mixing lots of
> different technologies when you can use one? (If you really need peak
> performance you could use JNI with ANSI-C on the serverside)
Clouding the issue again :-)
The comments regarding applets have nothing to do with C or JNI. Again I'm
trying to say that applets do not make sense in the context of HTML. It's
not Java's fault, it's just how things are.
> > I wish people would stop comparing a current Java idea with an outdated CGI
> > one. If you want to compare it to CGI, please do us the favor and compare
> > it to current CGI ideas.
>
> And I wish people would stop comparing a current CGI idea with an
> outdated Java one ;)
> Java was designed with JITs in mind. Why would the bytecode assume a
> stack-architecture (which is simmilar to intermediate-code of "normal"
> compilers) if not to compile the last stage?
I've never denied JAva's thread abilities or JIT capabilities, nor bytecode,
and the like. I frankly don't see its relevance for applications vs.
applets, as I've already granted you that performance is not so critical
there.
> public class chu extends ChrisHübsch implements TUChemnitz {
OK, you have beeen programming Java WAY too much :-)
> String email = "mailto:[EMAIL PROTECTED]";
> String SMSMail = "mailto:[EMAIL PROTECTED]?Subject=SMS: info";
> URL homepage = new URL("http://www.tu-chemnitz.de/~chu/");
> Talk talkto = new Talk("[EMAIL PROTECTED]");
> Integer ePlus = new Integer(4628555);
> }
