Re: Portals vs Links

Andrew C. Esh ([email protected])
Fri, 5 May 1995 08:55:45 -0500 (CDT)


On Fri, 5 May 1995, Clay Fouts wrote:

> > The problem is that, in the real world, there is no separation of
> > "what you can see" and "what's physically transportable into". (Modulo
> > closed windows and such, of course, but those are readily modelable
> > with even the technology we've already got.) It seems unintuitive and
> > jarring to me that there is any real difference.
>
> Why not present the option of having _both_ the link and the portal?

The way I see it, a link is merely a browser which has put a miniature
view of one world into some sort of contruct in another world. It could
be a view from a window, or on a television screen, or a 3D view into a
fishtank. Where and how the remote world is to be viewed is up to the
local world. The display problems are simple for the browser to handle.

The portal is different. If you can see through it, then it is a link as
well. A good browser should be able to make all the 3D display changes as
you walk through the door. I could even resolve differences in coordinate
systems.

The main problem I see with portals is the one-way-ness they have from
being modeled after HTML links. Doorways in hte real world are two way,
unless they are turnstiles. If we are going to model the real world to
some extent, then portals between worlds have to be two way.

Now, the problem with this is that the portal has to be visually
represented in the target world. What if the target is one small room
that has something interesting in it, and thousands of people make a
portal connection to it in their home worlds? The room can't contain
thousands of doors, and even if it did, how do you find the one you came
in through?

What may help is to have the author of each world define a point of
entry. Each point of entry is a different URL. When you go through a URL
to a remote world, you know that there will be a locally defined,
fitting, non-arbitrary doorway back to where you just were. The browser
has to decide where that is. The point of entry does not have a
particular outbound URL. Only an inbound one. I realize this is not in
keeping with the real world, but the real world does not support
user-constructed hyperlinks into any particular space. What decides the
origin of the incoming link is outside the control of the local server.

Maybe the best way to model an entry point (given that no example exists
in the real world), is to simply put the newcomer in the center of the
space, at location 0,0,0. If they walk around, and then hit the back
button, they are taken back, without having to return to 0,0,0. This also
obviates the need to create a doorway in every space which leads to some
unknown, browser determined place. Another idea, for rooms, would be to
designate a target spot, and have newcomers simply drop out of the ceiling
and land there. That way they get a bit of an overview of the room as
they fall (a little GopherVR lingo here).

For doorways that are supposed to have some persistence in their
connection, each end of the doorway (portal) must have a hardcoded URL,
which always takes you to the same place. This means the authors of the
two worlds have to agree to be linked at those points.

Here's a chance for a little cooperation, which will, in and of itself,
provide an interesting set of results. It seems to me there will evolve a
set of social rules about how doorways are created and maintained. What a
person thinks of you may determine how they decorate the doorway from
their space into yours. We may have to add a keystroke which will read the
URL from a particular doorway so we can see if it has been redirected to
go to a different place, or simply that the remote author has changed the
look of the target room.

We have to talk about this more. There is nothing like this now, and it's
obviously an important point. The links are what holds the Web together.
It is the same for VRML spaces.

---
Andrew C. Esh                 mailto:[email protected]
Computer Network Technology   [email protected] (finger for PGP key)
6500 Wedgwood Road            612.550.8000 (main)
Maple Grove MN 55311          612.550.8229 (direct)
<A HREF="http://www.mtn.org/~andrewes">ACE Home Page</A>