From: broehl@sunee.waterloo.edu (Bernie Roehl) Subject: Re: TECH: My standard is better than your standard. Date: Thu, 2 Jul 1992 03:47:54 GMT Message-ID: Organization: University of Waterloo In article <1992Jul1.030333.23800@u.washington.edu> s047@sand.sics.bu.oz.au (Jeremy Lee) writes: [quoting someone... possibly me... too many >>'s to keep straight...] >>I suspect C and C++ will be >>the languages used for VR work for years to to come. > >I think that we have different ideas here. I personally don't care what >language you use to write the basic system, what I am arguing about is a >language to be used *inside* the VR. While you are in there. Ah, I see. Sorry, I had misunderstood you. Sort of... you see, I think we have slightly different concepts of "what happens where" in the networked VR. More on this later... >>The entire trend in the computing world is [...] >>towards networks of smaller machines working together. >Undoubtably. But currently, to implement the system I have described, >you are going to need a *big* computer. Which is why I think the system you have described is too complex! :-) >How else can you shove an object across to a different environment? You don't! And therein lies the difference in concepts that I mentioned earlier. I believe that if I build an object, then one and only one copy of that object exists and the code that implements it lives on precisely one machine. You want another object like it, you make a copy of it (possibly on another machine). An object may travel from place to place, but the code that handles the messages for that object stays put. Just like I do -- when I travel around the virtual universe, the process that handles my interactions (ideally via datasuit!) runs on one and only one machine (the one I'm signed on to). I interact with other objects by sending them messages and responding to messages that they send me, not by sending copies of my executable code around the world on the Internet (or whatever). Human beings are just interesting objects as far as the system is concerned. >If you run a distributed environment then you are going to >have to have some sort of standard. If the objects that you created were >confined to sitting only on your local machine, then things are not >going to go well. Will they go better if my datasuit has to send every muscle twitch, stretch and yawn half way around the world before my local image of myself gets updated? I think not! >>I think it'll be a heck of a lot sooner than that. I think we'll see low-end, >>commercial VR systems within the next 12 to 18 months. >I stand by my conviction that we do not yet >have the computing power, unless you have unlimited access to >supercomputer, to do VR. And I stand by my strong disagreement with that point. It sounds far too much like our local computing centre, which for years and years insisted that you can't have computing at a University without a big central mainframe. They were wrong -- very wrong. > Until then, an affordable VR system will be little more than a toy. "These silly little machines people are getting on their desktops are just toys -- with a good communication program, they make a nice terminal to our big IBM mainframe, though". >I don't care about hardware. I do. You need hardware to run software, and software (and standards) can only run on hardware which *exists* (and is readily available). >Which is why you have to define a standard that is extensible. Agreed. But if it requires more computing power than most people can afford in the near future, it'll be a standard that no one uses. How many people program in ADA -- language of the future? How many people are actually using the OSI protocol stack -- networking system of the future? What about Topview -- operating system of the future? The last thing we need is "XYZ -- VR protocol of the future". >Can you redefine C >so that at the beginning of the compile you give it a whole bunch of >EBNF diagrams which totally redefines the language? Sure -- just write a preprocessor. (Most C compilers already have one). Better yet... just use YACC. >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? 24 hours I could live with. Ten years? No... -- Bernie Roehl, University of Waterloo Electrical Engineering Dept Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca BangPath: uunet!watmath!sunee!broehl Voice: (519) 885-1211 x 2607 [work]