> Debbie said:
> > Also a more modular approach
> > - do we really need video, avatars, whiteboards, etc etc or should we be
> > thinking of a toolkit approach where we pick-and-mix according to the
> > situation.
>
> In the workshop on Virtual Environments and WWW at the recent Web conference
> in Paris this was one of the things that several groups picked up
> on -- browsers and such like are become huge, one-application-fits-all
> type things, but from the point of view of a designer/user creating
> a new tool, what we need is a more lightweight, component-oriented approach
> which allows us to put together new applications quickly.
Definately, this is something I've been in favour of for some time and was
the sort of thing I was aiming for with the AVIARY work. Most current VR
systems that I've used force the application writer to build large
monolithic applications and make it very hard to support application code
re-use or application level parrelism.
> Interestingly, NCSA had a BOF session later in the week in which
> they announced that they intend to break up Mosaic into smaller
> functional units (HTML parser, HTTP component etc.) so that it
One of the things I've been doing at SICS is porting some of my DIVE 2
applications (like VR-VIBE,
http://www.crg.cs.nott.ac.uk/crg/Research/pits/pits.html) to DIVE 3. DIVE 3
is a big improvement over DIVE 2 for several reasons but the ones relevant
here are:
- scripting using Tcl/Tk
- ability to publish user defined info as part of DIVE objects (DIVE
properties)
- application level inter-process communication via Tcl
VR-VIBE in DIVE 2 was a large monolithic beast that included visualization,
user interface (including the implementation of 3D widgets etc), web
support, and code to interface to a database of people for author searches
etc. It was large and messy.
Under DIVE 3 VR-VIBE is simply an "agent" that performs layout. It has no
user interface - thats coded separately in Tcl/TK (as is the web support
that comes with DIVE 3), the people lookup will be also done by a separate
agent.
In other words the extra features of DIVE 3 let an application writer move
to a model in which the application becomes a set of small modular agents
that each perform specific functions and which can be composed in various
ways.
As a test of this I wrote a search agent application on Tuesday that
generates agents embodied in the virtual environment that search for
documents. In DIVE 2 this would have meant adding this functionality to
VR-VIBE itself. In DIVE 3 the agents simply examine the information that
VR-VIBE exports as part of the visualization - VR-VIBE doesn't even need to
know the agents exist unless they ask it to perform a service for
them. The DIVE 3 solution is more flexible (it would probably work on any
similar visualization) and was far simpler to write than hacking VR-VIBE
would have been.
Dave
-- Dave Snowdon Communications Research Group Tel: +44 (0)115 9514226 Department of Computer Science Fax: +44 (0)115 9514254 The University of Nottingham E-mail: dns@cs.nott.ac.uk Nottingham NG7 2RD, UK <http://www.crg.cs.nott.ac.uk/~dns/dave.html>"This mind intentionally left blank"