> It doesn't have to be that way though. Take Gopher as an example. People
> can setup their server and announce it to whomever they want. While
> people are using the server it can be registered by sending email to us
> (the Gopher team) or by an on-line form.
>
> The advantage to being registered isn't so much that you can be listed
> in the list of Gopher servers. The coool thing about it is that a
> server can be placed in a hierarchy - we choose the hierarchy to be based
> on geographical location; continent/country/state(province)/city
>
> Something like this will be **very** useful to have. Right now HTML
> pages are scattered all over the place. It would be nice if VRML
> documents don't fall into the same trap. Putting all VRML documents in
> some sort of hierarchy would be nice. As an example, if all VRML
> documents were to be placed in a hierarchy based on their geographical
> location it would be very easy to use the hierarchy to actually map
> VRML to the Real World.
>
> So when I get on a VRplane(VRmonorail/VRBART/.....) from Mpls to the
> Bay Area I can use my current knowledge of where things are in the
> Bay Area to help me cruise around Cyberspace. I know where I need to
> go to find SGI, SUN, Apple, City Lights, the Bison, and Amoeba Records.
I live in Los Angeles.
My PPP ISP is in Phoenix.
My .html files are on a disk drive in Manhattan.
The virtual world I created via HTML is a castle in outer space.
Where would you locate *me* geographically?
While the idea of cataloguing and listings is useful, let's not limit our
options by relying on The Real World as our metaphor.
\/0!d
voidmstr's law (tm): bandwidth expands to fit the waste available
[email protected] | [email protected] | [email protected]
Visit CastleVoid! <URL:http://www.phantom.com/~voidmstr>
\/0!d
voidmstr's law (tm): bandwidth expands to fit the waste available
[email protected] | [email protected] | [email protected]
Visit CastleVoid! <URL:http://www.phantom.com/~voidmstr>