I agree that confusion is beginning to reign here. The issue is whether to
base everything on a scripting language, thereby requiring that any existing
VR simulations be rebuilt using this scripting language, and that all new
simulations be constructed from a single set of primitives, or to use an API
which defines a standard set of interprocess communications protocols,
thereby allowing existing simulations to be incorporated in binary form and
new simulations to be constructed with the best tools availabale.
I am worried that if we try to come up with a definitive "VR language," no
one will come to our party. It is unrealistic to assume that engineers will
give up their favorite development platforms in order to develop
applications in VRML if a better alternative exists. Some will for purely
academic interest, but, when push comes to shove, the best development tools
will always win out. We have seen that an API approach is feasible. This
fact will not go away. I rather suggest that we should create a VRML that
is capable of coordinating and orchestrating API-based modules, allowing us
to embrace API advances without painting ourselves into a corner with a
language that predefines the possible range of capabilities of simulations.
**************************************************************************
* Michael D. Doyle, Ph.D. email: miked@visembryo.ucsf.edu *
* Director, Health Informatics Lab phone: (510)522-5275 *
* Department of Anatomy, School of Medicine fax: (510)522-4439 *
* University of California, San Francisco pager: (415)719-4557 *
* 5 Remmel Court http://visembryo.ucsf.edu/ *
* Alameda, CA 94502 alternate email: mddoyle@netcom.com *
**************************************************************************