Re: Hot Java is here! And it *rocks*

M Doyle writes:
>My point was just that there are many types of applications that Java
>can't handle or for which it isn't the optimal solution.  I'm not
>trying to put Java down.  I think that it is may represent the best
>kind of solution for handling GUI elements in embedded apps, for
>example.  APIs, on the other hand, are good practical solutions for
>high-performance embedded apps now.

Why embedded?  No, seriously - do we really need embedded apps?  Am I 
the only one who thinks that launching xv to view external images is
a Good Thing ?  Forcing xv to do its work through Mosaic or Netscape
would seem to be a roundabout way of doing things, to say the least.

In order to handle multiple files or a continuous data stream, 
what is basically needed then is a mechanism for handing an external viewer
the open connection, instead of handing it the resulting file.
viz. the new Netscape 'inefficiently animated icons' hack.

Of course, this means that the client can start handing off all sorts
of connections, not just HTTP connects, but FTP, Gopher things, some
new session based protocol communicating with a rendering engine or a
proprietary protocol for playing Blackjack with other clients logged
in to the same server.

Do these apps really need to be inlined into the browser? No.  Do they
need to communicate with the browser? Yes - CCI is a step in the right
direction, although I keep thinking that a better operating system
would make this a non-problem (Consider the paradigm 'web application
as scriptable OpenDoc part' or even just a web browser built out of
SOM objects).  Trying to graft IPC on top of systems that really
weren't built for it seems to be ... an exercise in frustration.

>>To me it looks like   Java + scripts  == Eolas + n helper apps
>Not even close.

What's the big payoff that Java is missing? Direct interaction with
server side apps/renderers ?  Maybe we should look into the
possibility of Java and CCI++ coexistence.  Java seems to suit local
rendering needs quite well (image maps, simple animations, UI tweaks),
while CCI++ appears to handle the larger issue of 'not all client-server
interaction is stateless HTTP', hence they seem more complimentary than
competitive.  Of course either one could be used to do tasks the other is
better suited to, but the same can be said for Perl and C++.

Using CCI to hook up to a big rendering engine seems to be a good idea -
controlling the inline image using Java might be a possible alternative to 
writing an external renderer (if you want to go for embedded interfaces).

Using CCI to hook up to a simple animation engine is a waste of bandwidth.
(Once you have sent the first n frames of animation, there is no need to send
them again.)

Christian "webhead <*>"

Received on Tuesday, 28 March 1995 04:30:35 UTC