Subject: Re: CCL:Java and other WWW developments

From: Craig Taverner <[email-masked]>
Date: Mon, 15 Apr 1996 09:13:22 +0200 (GMT+0200)

> specific needs (including e.g. chemistry-related Web applets), we can
> very well choose not to follow the mass-market trends.

We agree that we must make the most informed decision about what trends 
to follow, but we must also try and predict where we think the chemistry 
market is going to go.  It would be foolish both to waite too long for 
the trends to become apparent, and get in just as the next wave comes, as 
well as to get into something new that never takes off.

I think the work being put into Java is justified and it is going to have 
an impact in chemistry.  We must be in a position to make the most of 
what does come out of the current situation.  I beleive we must also be 
in a position to try and make sure that what might come out is something 
to our liking.

In fact, we should stop discussing just whether we should discuss it, and 
get back to the original discussion of standards that we would like the 
developers to follow.

> Enthusiasm about the possibilities, yes. But that's something else than
> talking about a "new standard" and unavoidable developments that we
> just have to follow.

Java is an alternative development platform.  We cannot touch that.  But 
we can be involved in the Chemistry and Computational Chemistry standards 
or trends that might be implemented.

> One of the problems with Java is, for example, that is not really
> free.  To make the most of Java applets (or even just classes), it
> would be necessary to be able to integrate them with other code, which
> is not necessarily Web-related. But this requires licensing the rather
> expensive byte-code interpreter from Sun, which is a prohibitive cost
> for small developers, including academic groups. A real standard for
> computational science should be fully available to everyone at an
> acceptable, preferably zero, cost.

Java is free.  You only have to pay the licence fee if you want to 
develope a byte-code interpreter yourself.  This is not our market.  In 
order to interface with other code, all we need to use is Java's 
interfacing code.  I understand there are some bugs with it, but it will 
certainly be an option.

Cheers, Craig

"Imagine if every Thursday your shoes exploded if you tied them the
 usual way.  This happens to us all the time with computers, and nobody
 thinks of complaining."
                -- Jeff Raskin, interviewed in Doctor Dobb's Journal

Craig Taverner
Structural Chemistry, University of the Witwatersrand, South Africa
tel:   +27-11-716-2290                fax: +27-11-716-3826
email: [email-masked]
www:   http://www.gh.wits.ac.za/craig

---

From: [email-masked] (Konrad HINSEN)
Date: Mon, 15 Apr 1996 09:40:49 -0400

> develope a byte-code interpreter yourself.  This is not our market.  In 

You can develop your own bytecode interpreter for free, and in fact
there are projects for alternative interpreters at various stages of
completion.  It remains to be seen whether these clones together with
Sun's original can be used interchangeably and thus form an open
standard, or whether each version will try to attract programmers by
special noncompatible features, the way Netscape is about to destroy
the HTML standard.

> interfacing code.  I understand there are some bugs with it, but it will 

But a very limited one, even if it works as advertised. With the
interfacing code, all you will be able to do is to call non-Java code
from a Java applet. You will *not* be able to run Java code outside
your Web browser.

If someone invests a significant amount of time to develop Java code
for visualization, access to chemical databases, etc., to make these
things available in Web pages, it makes sense to use the same code for
other applications *outside* of Web pages. But that requires the
integration of the bytecode interpreter into whatever other system
wants to use Java code.

Another point worth considering is that Java-capable Web browsers are
not available to everyone. Although everyone talks about Netscape 2.0
as "the" Web browser, it isn't available for some widely used systems
(e.g. SGI Irix 4.0, or MIPS-based DECStations). And this situation may
become worse in the future.

Suppose you develop lots of interesting chemical software in Java, for
use in special Web pages constructed for Netscape. Then a new machine
appears on the market that is just perfect for computational
chemistry: very fast, lots of memory, and very cheap. But Netscape
won't port its browser, because this machine is not terribly
interesting from a global market perspective. What do you do?

-------------------------------------------------------------------------------
Konrad Hinsen                     | E-Mail: [email-masked]
Departement de chimie             | Tel.: +1-514-343-6111 ext. 3953
Universite de Montreal            | Fax:  +1-514-343-7586
C.P. 6128, succ. Centre-Ville     | Deutsch/Esperanto/English/Nederlands/
Montreal (QC) H3C 3J7             | Francais (phase experimentale)
-------------------------------------------------------------------------------