Hello Mark;
> >The *only* thing that VRML and WWW share is the use of URLs.
>
> This statement is incorrect.
> Without sounding to repetitive, let me state again: VRML is a *networking*
> technology. VRML happens to share libwww, which is HTTP, FTP, etc.
> (otherwise WWWInline wouldn't work), and will most likely use features
> garnered from HTTP-NG, RTP, MBONE, JAVA, and other technologies. These are
> network technologies. As few of you have perhaps implemented VRML browsers,
> let me share some of my experience with you: Very very little of the work
> is in the graphics and rendering- much much much of the work is in the
> networking.
Mark, with libwww behind you what else is there to do in terms of
grabbing a URL? You are being tricked by the names WWWAnchor and
WWWInline. I raised this point a few weeks ago, those names should
really be URLAnchor and URLInline, that is what is implied anyway.
VRML is an infosystem of its own. Its goal is to apply a layer of
abstraction between the user and current/future Internet services.
What are these services: Gopher, HTTP, Hyper-G, WAIS, FTP, Telnet,
MBONE, JAVA, etc etc.
What is the level of abstraction: a virtual reality, compelete with
interaction between the user and the virtual reality.
VRML defines the abstraction, not the service.
For example, VRML does not care what direction JAVA goes off to. As
JAVA gets better and better, the people working on JAVA will create
the networking tools to move JAVA through the Internet. It is the JAVA
people that will decide how to best provide the service of JAVA to
the Internet. Not VRML. VRML will merely say, resolve URLs. If the
URL happens to say this a JAVA item VRML *browsers* must know how to
deal with JAVA, NOT the VRML spec. The VRML *browser* will know what
networking libraries to call in order to deal with JAVA.
Remember what VRML was initiall called? VR Markup L, then it became
VR Modeling L. VRML "models" a virtual world. It doesn't care what
URLs you stick in it. That isn't it's goal, that shouldn't be its goal.
VRML isn't a *networking* technology. It is a way of presenting already
existing and future networking technology to user of the Internet.
Here in GopherVR land we haven't implemented a VRML browser, but we
have implemented a GopherVR browser, and the two aren't as different
as people might think or want to think. We can cruise the Internet and
FTP items, watch movies, look at HTML files, look at PDF files, and more.
All this in a 3D virtual world. And I can tell you, we did not create
any new networking technology to do this.
> As far as I know, VRML has very little more progress to make on the
> "graphics" front. Sound is not a graphics issue, nor is caching nor, even,
> is interactivity. The first and last of these are clearly more
> network-based issues/implementations than graphics technologies.
VRML doesn't make progress on the graphics front, I think we all
agree with that. But it also doesn't make progress on caching or
sound. For example, the VRML spec doesn't say how 3D objects are
to be cached. VRML does define interactivity, nobody else has done it
before, not to a large extent anyway.
A lot of what VRML does IV does (BTW: why is it that all of a sudden
its a bad thing to relate the two and to point out that VRML borrowed
a lot from IV? IV does a really good job of doing what it set out to do,
I don't understand why people want to distance the two - personal view)
"all" that it different is the notion of the magical URL.
> My recommendation stands: comp.infosystems.www.vrml
I'd vote for comp.infosystems.vrml for all the reason's stated above.
*BUT*, an even better place for it would be sci.virtual-worlds.vrml.
BTW: this isn't a flame or flamebait (as Paul Lindner's last mesage was
labeled by someone out there ).
--------------------------------------------------------------------------------
Neophytos Iacovou Distributed Computing Services
University of Minnesota 100 Union St. SE
email: [email protected] Minneapolis, MN 55455 USA