> Date: Tue, 6 Sep 1994 10:49:42 -0700
> From: mddoyle@netcom.com (Michael D. Doyle)
> Subject: Re: Scripts vs APIs
>
> 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.
Several remarks:
1) An "interprocess communication protocol" needs to have a protocol
defined. That protocol could be VRML. So asking for an API for this
does NOT make the need for a scripting language go away, but only
exacerbates the need.
2) I thought that VRML was to be more "file format" rather than "language" --
i.e. no operator constructs, no variables, no subroutines. Did I miss
a paradigm shift in this newsgroup?
3) I would like to see a nice, clean file format, since there must be 100
of them out there, and they all !@#$%^&* STINK !!!!! I'm hopin VRML won't!
4) > thereby allowing existing simulations to be incorporated in binary form and
> new simulations to be constructed with the best tools availabale.
I don't see how VRML would prevent you from doing this. Besides, what
can you mean "in binary form" when you've gots a MIPS or SPARC or whatever,
and I've got a PowerPC, or 586, or whatever? VRML allows processor-independent
and operating-system-independent sharing of geometric data. As per
remark 1) above, an API can't do this, without ALSO defining a protocol.
> 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.
What, precisely, is it about VRML that has limited your possibilities?
> **************************************************************************
> * 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 *
> **************************************************************************