Re: [vwrap] Definition of "Virtual World", in a protocols context

[Carlo Wood <[e-mail]>]

As you might have noticed, I stopped writing to this list
a while ago (and reading it I must admit). The reason
for that being that I "gave up". I had the strong feeling
that people don't listen and any time invested in this
project from my side is wasted.

Nevertheless, I decided to write another post...

So, why would you listen to me? Who am I? I can only
answer that with something that will sound rather arrogant,
but I assure you, are just facts, not opinions: It is
not uncommon for me to understand things that everyone
else around me seems to miss (until they listen to me).
I've been tested officially (with an official test,
in an official test room by an official psychologist)
to have an average intelligence in the top 0.01% of
the general population. But I REALLY have a gift for
the things: abstract comprehension, spacial insight
and analytic insight. Imho, the latter matters in
this case. I've also experience with related matters
(see http://www.xs4all.nl/~carlo17/irc/run-irc.htm).
The things in the design for IRC that map 100% to a
protocol for VW's are... well, almost everything:
targets, (routing?), uniqueness, scalability, flow control,
Identities,... And the same holds for other design issues.
In other words, years of thought and experience.

========================================================

Back to VWRAP.

There are a lot commonalities between "the web" with
http as the protocol, and VWRAP. It's absolutely not
the same, but it seems an access point to understanding
that works with most people.

Down to earth, we are and will be dealing with (virtual)
servers: machines on the internet with some IP number
(ipv4 or ipv6 who cares).

The most important difference between those servers is
and will be who controls them. That can be an individual,
or an organisation. For common understanding lets say
that servers that belong to the same "who controls it"-class
have an internet domain name that is the same.
Remember, this is just a model to allow understanding.

[In reality it's not the virtual server that is the
smallest element in the whole, but the applications
running on them. And then I don't even mention that
I left the viewers (clients) out, although you can
call them 'server' too if you wish. Clients are
"leafs" (sort of) however, and therefore not a source
of great confusion here. For the purpose of understanding
we can (work with a model that) assume(s) that applications
running on the same machine and that have the same IP
number -- or even that have different IP numbers but
with the same internet domain (ie, if both run in
a virtual server each with their own IP number) --
are controlled by the same organisation.]

Conclusion: it is very workable, for understanding
and analysis purposes, to consider applictions running
on servers with IP numbers in the same internet domain
to be controlled by the same organisation.
I'm sorry to overload your terminology, but let me
call this simply a DOMAIN from now on (in this post).

A (network) "protocol" is a language for communication
between *applications*, however it has never been needed
to have a *standard* for a protocol used within one
and the same DOMAIN. Examples are secondlife.com,
efnet.org, etc. Put very simplistically, that is
because every server within a given DOMAIN runs the
same (version of) application, and therefore automatically
use the same protocol-- defined by the source code of
the application (it is communicating with itself so to
say). Here the special role of the viewers comes into
play: the viewers are in many cases not directly
controlled by the same organisation (after all, they
run on machines owned by others, not by that organisation),
which DOES give rise to the need of a client-server protocol
document, but not as much as we need (see below) because
the DOMAIN owner usually has a lot of power and can
control which clients connect...

I use(d) DOMAIN here, surely colliding with the meaning
of that word ELSEWHERE, because I don't want to type
"Applications connected over a network, most likely
the internet, and communicating using some protocol,
whose version, and therefore the protocol (version)
is controlled by a single entity (called 'organization'
above)" every time.

We must realize however that this model so far is FUZZY.
It is NOT exactly defined. We already saw the problem
of needing a protocol document "some how" for the
client-server protocol (although one approach is to
release binary clients by the SAME organisation).
But at least as important, probably even MORE important
is the fact that a protocol evolves over time: it
changes! Lets call this a "protocol version", even
though the protocol may not be clearly documented and
as a result doesn't really have a version. But wait,
we only have ONE domain (so far) and thus the SAME
server application everywhere and since that controls
which clients can connect, there is hardly a difference
between the *application* version of the server, and
the protocol version.

In this model, with a single DOMAIN, it is almost
trivial to "solve" the protocol changes over time
by constantly having at most two *server* versions
running: N and N+1 and making sure they are compatible.
Then it is possible to "slowly" migrate from 'protocol'
version N to N+1, by upgrading the servers one by one
from version N to N+1, and so on.

----------------------------------------------------

Our Problem

I've seen the question on this list 'what we are doing'
too many times. "What are virtual worlds?", "how
many virtual worlds do we have?"... Blah.
Forget all that. Empty your mind and just consider
the text that I wrote above.

What problem do we REALLY face here? When designing VWRAP.

... I almost decided to mail this post right here,
because if it isn't obvious at this point you will
never get it.

Nevertheless, let me continue.

The goal of this commitee is to design a well documented
protocol to allow communication of applications from
*different* DOMAIN's (as defined above). And that opens
a lot of cans with worms:

1 The protocol suddenly becomes static. It cannot be
  upgraded anymore (unless we specifically builtin
  a method for that!)
2 The trust (level) between DOMAINS comes into play,
  which was non-existent before.
3 There might be differences between DOMAINS: from
  the fact that they run their own server implementations
  that are radically different from the others (no
  more version N and N+1, or anything that compares)
  to any thinkable difference at any level of the
  whole experience.

It is our goal to define and write a protocol that
addresses these three things. In general terms the
solutions are:

1 Include protocol negotiation IN the protocol, to
  allow the protocol to evolve (slowly change over
  time).
2 While writing out the protocol details, keep in
  mind that we can't necessarily trust the other
  server.
3 Make the protocol as flexible as possible for
  possible differences between DOMAINS, without
  making a finite list of those possibilities.

Imho opinion-- ok, not so humble-- point 3 is nearly
the same as point 1: It can ONLY be satisfactory
solved with protocol negotiations. That will allow
*future* differences to be resolved that we can't
take into account at this moment.

--------------------------------------------------------

Prologue

If one considers the virtual experience while connected
with a server of a given DOMAIN to be "the same", and
this experience is (slighty) different while connected
to a server of another DOMAIN (because that organisation
wants things different), then it is logical to speak
of different virtual "worlds": when teleporting from
one DOMAIN to the other, it is as if you travel between
planets.

On the other hand, if the protocol succeeds and you
can as flawlessly as possibly teleport from one DOMAIN
to the next in a way that is painless and realistic (ie,
you still look the same, and it is mostly a feeling of
having travelled between places) then you might more
think of it like travelling between countries and still
be on the same world. In that case ONE virtual world
would be the whole of places you can reach with teleporting.

None of that matters however. What we should concentrate
on is a description of the protocol in the light of
the three points mentioned above.

-- 
Carlo Wood <[e-mail]>