From: mhughes@visual.spk.wa.us (Mark Hughes)
Subject: Re: TECH: My standard is better than your standard.
Date: Wed, 01 Jul 1992 17:41:49 GMT
Message-ID: <1992Jul01.174149.563@visual.spk.wa.us>
Organization: The Visual Market Public Access Site - Spokane, WA


(Jeremy Lee) writes:
> >Once a standard is adopted, even if it's a *bad* standard, it tends to stic
> >like molasses.  Getting there first is much, much more important than anyth
> >else.
> 
> NONONONONONO!! The first one there is traditionaly the one that fails.
> It's always the second or third which made a considered entry that
> became the standard. If you rush in "to be first" then you will fail.

  Not always - sometimes the first one there just really screws things up for
the rest of us for all eternity.  I'd prefer a simple, but extensible, standard
to start with, just to take the high ground, and then reinforce it and improve
it once we're there.

> >We must develop *good* standards that work *now* -- a standard designed for
> >ten years from now will wind up being a footnote in the history of VR.
> 
> OK. I'll do that. Right, everybody is now only allowed to work on IBM
> '286s, because that's the current level of widely accepted PC use.
> Anything else won't be available to the general public for, oh, two or
> three years! :-)
> 
> Don't you think it is slightly better to develop a *brilliant* standard
> that works tommorow, knowing that tommorow will actually arrive in
> slighty under 24 hours? In any case, "Standard" is deceptive, because
> any "Standard" should be, but should allow modifications to be made and
> communicated through the "Standard".

  I agree almost whole-heartedly.  Postscript and X-Windows came out of that
design philosophy too, and you know what pigs they are...  A very simple
base language, which can extend itself (like FORTH without the damnable RPN)
would be the best.  Perhaps a modified LOGO...  The point being to have a 
"VR language" that is interpreted (or semi-compiled) by any one of dozens
of implementations...  just like Postscript...

  But here's the real questions:
1) How do we want to store the object information?
2) How do we want to handle collision/event messages?
3) How do we want to handle objects that are distributed across many processors?
4) What *MINIMUM* commands are needed in this language?

  I would prefer a term other than "language" for this, though, since that has
too many connotations of compiling this language into a program - and that's
the Wrong Way to do it.

  - Mark Hughes                               mhughes@visual.spk.wa.us
 "Naturally, everything is my opinion or somebody else's, and if it's somebody
  else's, they should get it out of my message, dammit!"