[mmox] One more time: The LESS model vs the Generic Client model

[Jon Watte <[e-mail]>]

Morgaine wrote:
> I don't fully understand what the highlighted phrases mean.  On the 
> face of it, your words "/two clients ... two different worlds/" seem 
> to suggest that you're advocating that users should have one client 
> per virtual world, but since we're envisaging a metaverse of millions 
> of worlds and thousands of VW providers, that can't be what you mean, 
> because thousands of clients on a desktop is, well, bizarre.
>

It seems that you have not yet grokked the operating principle of LESS. 
Think of it as cell phones: you have one cell phone, that works with one 
carrier. However, you can call people on any other network, and it is 
transparent to you, because your carrier/operator makes the translation 
for you. That's the model I see working with LESS -- the different 
virtual worlds translate for you.

Thus, if you only have a Second Life client, and you click on a link to 
go visit a location that's hosted by an OLIVE server, what will 
technically happen is that a Second Life sim sets aside a little bit of 
"empty space," puts your avatar in that space, and connects that empty 
space with the location hosted by OLIVE. Any objects that you introduce 
in your space (including your avatar) get peered to the location host. 
And objects from the location host get peered to your system. You view 
the outcome of the simulation of all objects (hosted on OLIVE, or hosted 
on Second Life) through your Second Life client, because the peering 
gateway on the Second Life side translates from LESS to the Second Life 
native technology. Similarly, the OLIVE user views the outcome of all 
the objects from the Second Life side through the OLIVE client, because 
the OLIVE gateway translates from LESS to the OLIVE native technology. 
Note that only the presentation of the object needs to be transmitted 
(Second Life style), not the behavior, scripting, or internal ownership 
details of the object. (This should make people who worry about IP happy).

This way, you only ever use one client -- the client of the operator of 
your choice. This is very similar to how you select a cell phone and a 
carrier. Operators may support multiple clients, but the protocol 
between client and operator does not need to be standardized. It could 
be a separate standard, of course, but the technology involved is so 
complex that getting success in the market with this model is next to 
impossible.

Now, why is the cell phone model better than the web browser model for 
virtual worlds? I think there are two reasons:
1) It's about real-time interactivity, not asynchronous interactivity. 
You find that all interactive systems actually end up with the 
client/server customer/provider paradigm. This goes for Instant 
Messaging, or online games, or regular old phone service as well -- even 
for e-mail, which actually isn't real-time. You could say that the HTTP 
web model is the odd man out -- it works very well for asynchronous, 
not-very-complex data, but as soon as you need more complex data (Flash 
games, streaming video, etc) you end up with a number of competing 
tightly integrated client/server set-ups (QuickTime vs Real vs Flash vs 
Microsoft for video, for example).

> For interop to happen, all parties are going to have to develop new 
> interfaces /somewhere/, either in their servers or their clients or 
> both, but it's their own choice where.  In your case the new 
> interfaces seem likely to appear in OLIVE or LESS servers, as that is 
> the model you prefer.
>

I hope I made a case for why that's actually the only model that I see 
as commercially viable for the greater world of virtual worlds. 
Implementing LESS peering between servers would be an order of magnitude 
less work than re-implementing an entire client/server architecture, 
unless you keep dual architectures in the client (one "simple" for 
interop, and one "native" for some "home" system -- but down that path 
lives madness). Note that the OLIVE internal system is nothing at all 
like LESS -- in fact, LESS is a lot more like the Second Life protocol 
than like the OLIVE protocol. The reason LESS is designed the way it is, 
is that we (at Forterra) have implemented virtual world interoperability 
at the physics and semantic level between disparate technologies since 
2005, and have learned a lot about what is easiest to do to accomplish 
the most. We do, in fact, have an interoperability gateway on our price 
list -- but it doesn't use LESS; it uses DIS, or HLA, or a protocol 
proprietary to OLIVE. I'd like to get away from that, to a standard that 
everyone can use, and just plug bits together when building the systems 
that run the worlds.


> Since nobody is advocating multiple clients then, why do you keep 
> mentioning "/*not having to install two clients*"?
> /

It's a necessary logical conclusion from the model of a client that can 
connect to different kinds of worlds. Let me spell it out:
Today, you can download and install two different clients, to connect to 
two different worlds. That's the status quo. Those worlds may use OpenID 
if you want a "single sign-on" -- that technology already exists. */Any 
standards proposal must be viewed against this back-drop/*, to measure 
how far it advances the state of the art.

If we introduce a "multi-world" capable client, then you can choose to 
connect to world A, or to world B, from the same client. The gain, for 
you, is that you don't have to switch clients when moving to different 
worlds -- you don't have to install two clients to visit two different 
worlds.

However, what */you do not gain is the ability to mash up objects/* from 
world A with objects from world B. You have to choose: do I visit world 
A, or do I visit world B? Even if you log in to both at the same time, 
the users in world A do not see the users you see in world B, and vice 
versa. You need server peering for that to work. Which is what LESS is 
intended to provide.

What you also do */not/* get from a multi-capable client is */the 
ability for users in world B to see and interact with objects that you 
may own and use in world A/*. That requires a single, standardized 
object execution environment, kind-of like saying that all web servers 
should use ASP.NET for servlets. It also requires transfer of the entire 
object (scripting and other internals) to the second system. Or it 
requires server peering -- which is what LESS is intended to provide.

In fact, */you may not even get the ability to keep the same avatar/* 
looks and clothes between the systems -- that would require the systems 
to implement the same user interaction methods and protocols, as well as 
highly technical details like how to customize and build up an avatar 
out of smaller pieces of data. In LESS, the owning system provides a 
unified "cooked" presentation of your avatar, and is responsible for 
making it look right. Thus, technology-specific changes are applied 
before the data even leaves the originating system.

When implementing the LESS model, you get all the benefits that you want 
to provide in a multi-capable/generic/universal client model:

1. a seamless click-to-teleport experience, no matter where the destination
2. keeping a single client maintained, rather than a bunch of disparate 
clients

You also get the following benefits, which a 
multi-capable/universal/generic client will not give you:

3. keeping a unified avatar, with a single avatar identity and 
consistent visual
4. keeping a unified inventory with all your usable objects
5. interacting between users from world A and world B in a single space
6. using objects from world A and world B together in a single space

All of this, at an (estimated) 1:10th the implementation cost of a 
multi-capable/universal/generic client equivalent to the native clients 
we have today. To my mind, this is how to get the best bang for the 
least buck in virtual world interoperability, if you actually care about 
interoperating between technologies.
If you want to build a generic client, you can always build on top of 
the server<->server peering protocol at some later time -- but the 
server<->server peering still needs to be there to provide benefits 3..6 
above.

> This has confused me on various occasions so I've found it hard to 
> follow your line of reasoning.  Could you elaborate please?

I appreciate that you're asking for clarification, and I hope that I've 
explained the reasoning in sufficiently detailed steps. If there is 
something that still doesn't make sense, or some conclusion you disagree 
with based on some facts that I may have missed, I'd be very interested 
in hearing about it!

Sincerely,

jw



PS: The LESS protocol is a skeleton to build on: there are lots of bits 
and pieces that need to be defined. like how servers find each other; 
specific data formats for object presentation graphics data; what the 
specific sets of interactions should be; what the specific well-defined 
property semantics should be; etc -- much of which probably can be 
grouped into lower-to-higher profiles as well, to support 
limited-capacity clients and the like. Hopefully, the protocol 
description at least calls these out for further clarification.