Well, Viola's model was *demonstrated* in 1993, *released* freely in 1994.
But we may be comparing apples and kiwis here, and nevermind on this time
thing as far as I'm concerned.
> Furthermore, Viola merely implements an internal scripting language that
> allows one to code "mini application" scripts that are transferred to the
> local client, and then interpreted and run locally on the client machine. As
> Pei correctly notes in his paper, this is similar to the use of EMACS'
> internal programming capabilities.
Right, this is the basic approach in viola. The mention of OLE had me
suspect that your system does not use a scripting language. That's fine.
It's just another way of doing it.
> What we have accomplished is much different. Just as the Microsoft Windows
> OLE function allows any OLE-compliant application to be embedded, in its
> native form, within, for example, a MS Word for Windows document, we can
> embed ANY interactive application IN ITS NATIVE FORM within a WWW document.
> These program objects not only effectively encapsulate both data and
> methods, they also "encapsulate" computational resources, since the the
> program objects are, themselves, client server applications that actually
> run remotely on one or more distributed computational servers. The access
> of the remote machines is transparent to the user, allowing, for example,
> someone running a WWW client on a laptop to interactively manipulate and
> analyze huge datasets running on a distributed array of supercomputers
> distributed across the country.
Actually, you could do it different ways. You could have the viola object
running entirely locally, or have the object act as a front-end to a
remote back-end.
There's no reason why Viola's model can't also do a client-server
application (thou, OK, not now quite the way you do it). The chat-drawing
demo in the paper shows this. That mini app starts up, then makes a
connection to a message relay server.
And, as for the plotting demo, it actually is really just a front-end
that fires up a back-end plotting program (and the point is that that
back-end could very well be running on a remote super computer instead
of the localhost). For that demo, there is a simple protocol such that
the front-end app could pass an X window ID to the back-end, and the
back-end draws the graphics directly onto the window violaWWW has opened
for it. (Viola scripts are compiled to byte-codes for speed's sake, but
no, it's not fast enough to do the computation necessary for the plotting!)
Anyway, it sounds like what you have is a really defined standard interface
(akin to the OLE API), where as Viola's model doesn't have a one (yet :-)
-- Viola uses scripting rather than a stardard API for the glues.
> The applicability for VR systems is obvious. One of the major hurdles to
> widespread acceptance of VR technology has been the burden of large local
> computational resources. Our approach allows that computational burden to
> be distributed to suitable remote "visualization engines," thereby allowing
> users to employ low-end machines to access sophisticated graphical
> environments. It further allows easy access to those applications through
> the World Wide Web.
Yup. No argument here... There seems to be a few different ways to do VRML.
I was more interested in offering yet another piece of what it might take
to realise VRML.
-Pei