>in snowcrash, the top realm
>was the Strip, and everybody else just registered their realms with the
>Strip.
Okay, problem one: the word "register". The minute you introduce a
concept of needing to "register" your stuff somewhere, you instantly
introduce bureaucracy and hassles. I mean, think about the existing
technologies on the Net. Do you want your model to be Usenet, or the
Web? A large part of how the Web has grown so explosively is that you
don't have to register a damned thing, beyond getting onto the Net --
just put the stuff up, and it's there. I am absotively, posilutely
certain that *any* kind of registration will slow the growth of
Cyberspace by an order of magnitude, because the vast majority of
people just won't bother.
(This is a point of concern I have over the Cyberspace Protocol; I
don't understand how it can work without a central authority. But
Mark has assured me that it doesn't, and I don't fully grok it, so
I'm giving it the benefit of the doubt until I *do* understand it.)
The whole notion behind portals is that it allows Cyberspace to
self-organize, pretty much at will. What makes it tricky is doing this
without being hopelessly confusing and counter-intuitive spatially,
but I'm pretty sure that this can be dealt with with good
browsers. (One concept behind portals is that once you've passed
through a given portal from A to B, you establish a link in the brower
so that going *back* through will lead back to A. This works, so long
as you've got a concept of "entrances" and "exits". It produces a
concept of "local space", which isn't completely fixed forever, but
shouldn't be especially disorienting on a practical basis.)
>RE: Looking thru Portals
>i think that this is best handled by the WWWInline node (someone correct
>me if i have misinterpreted the node) because this allows the description
>of the portal to be designed by the host that the portal links to.
Yes and no. I think it's conceptually inappropriate to put it in
WWWInline, which simply imports an object; there's a lot more semantic
weight to this. And it's not clear to me that we want to mandate that
the remote site supplies the portal description; I think that there's
a lot to be said for being able to customize it to fit the local room.
Indeed, I don't really think of a portal as *having* a
"description". The notion of the portal, really, is that it's simply a
two-dimensional gate between worlds; both the local and remote sites
specify where that gate sits relative to their world, and the user can
see through the portal if the browser is smart and fast enough to do
the necessary prefetches. *Normally*, you'd put portals as the open
part of a doorway, but obviously there's lots of potential to play
with that...
Hmm. Do people think that this is an interesting topic? If so, where
do you think it belongs? I think it's premature, but only a tiny bit
so -- I *do* plan on trying to get this technology (or something else
capable of making Cyberspace properly contiguous and flexible) in VRML
2.0...
-- Justin
Who is still uncomfortable with the term
"world" for a defined VRML space; I still
think "room" gets the point across better
in most cases...
Random Quote du Jour:
"In England, anything not expressly forbidden is permitted.
In Germany, anything not expressly permitted is forbidden.
In France, even things expressly forbidden are permitted."
-- from the Wall Street Journal