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

[Jon Watte <[e-mail]>]

Morgaine wrote:
> That's exactly how I believe everyone has understood LESS to work, ie. 
> the servers do the translations, thanks for confirming it.  The 
> purpose of my post was to show that nobody is proposing a 
> proliferation of clients, and your explanation confirms what I wrote 
> myself, that it's not required by LESS.
>

Actually, I have seen the Open Sim people propose and argue for the 
"generic client" concept. Note that the proliferation of clients is the 
current state of the world -- it's not something someone is arguing for; 
it's what we have now.

> So that just leaves us with what's required by the OGP approach, and 
> this is where your understanding is breaking down and leading you to 
> false conclusions.
>
>
>
>     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 <http://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.
>
>
>
> That is entirely incorrect.  I gave the picture that applies to the 
> OGP model in my 3-world OGP interop scenario 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>.  
> Everything you say about the model is wrong --- its whole purpose is 
> to do exactly what you claim it does not do.  In every situation after 
> the initial conditions, A1 appears in worlds B and C creating object 
> mashups.
>  

Not by just implementing OGP, it doesn't. As I said, for that to happen, 
you need at least two other things to be true:
1) For the client to understand that communications protocol of all the 
involved servers (the equivalent of a generic client), and
2) For all the servers to provide the same execution environment for 
objects (the equivalent of forcing all web servers to use J2EE)

1) is businesswise impossible, because it's way too expensive with too 
little benefit for most world vendors out there
2) is politically not feasible

Both are also a bad idea technically, because it means that specifically 
tuned clients for specific situations (learning vs entertainment vs 
narrow-band vs LAN etc) are left out of the equation.

>
> It is up to each world itself to decide if you get to use your avatar 
> from another place in their world or not.  It may not be appropriate 
> for a laser-blasting space farer or a cell-shaded cartoon character or 
> a pin-striped businessman to appear in their world of orcs and 
> dwarves.  Other worlds will of course welcome avatar diversity 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg01020.html>.  We 
> are in the business of supplying mechanisms to allow it when it is 
> desired, not mandating any specific policy.
>

OGP supplies no such mechanism, unless you mandate the execution 
environment of objects on the servers, which is politically not feasible.

>
>
> You have not given even a single line of explanation of your "/*not 
> having to install two clients*/" phrase in the contexts I quoted 
> <http://www.ietf.org/mail-archive/web/mmox/current/msg01142.html> 
> (paying for clients), and  therefore I conclude that it had no basis 
> in reality nor addresses any known issue.  Such phrases are best 
> avoided as they create a false impression of intent.
>

Today, with customers and vendors paying zero dollars, you can achieve a 
certain kind of interop: being able to visit different, separate worlds. 
The user experience cost is to install two clients, and switch between 
them. For anything to be an improvement over what we already have, then 
the benefit to the user of the improvement must be such that it at least 
pays for the investment for the worlds providing that benefit, or the 
"improvement" is actually a loss.

> It is entirely up to each world provider to decide whether to 
> implement interop protocols in servers, clients, or both.  While OGP 
> does refer explicitly to clients or viewers, this role would be played 
> by a LESS server in your world, which would provide a proxy presence 
> in the remote world and translate the object representations for the 
> benefit of its clients.

This leaves aside the point that OGP isn't even implementable from spec 
as it is currently written up, much less actually useful to anyone other 
than Second Life interoperating with Open Sim. If that's all you want to 
accomplish, that's fine, but then you should not claim that your goal is 
vendor neutral interop. It's really a question of what we want to do in 
this group:

Correct me if I'm wrong, but here is my current take on the positions of 
the parties, based on statements made by representatives on this list:

1) Linden Lab has publicly stated that they are only interested in 
specifying how third parties, such as Open Sim, can interoperate with 
the Linden public grids. They have not shown any interest in 
interoperability on neutral ground with a large number of different 
technologies.

2) OpenSim and RealXTend representatives have stated that they want to 
help Linden Labs in those goals, but they are open to also doing other 
things regarding interoperability.

3) Forterra has publicly stated that we are interested in neutral-ground 
cross-technology interoperability. We have also stated that there is no 
way that OGP can deliver any kind of usable interoperability to our 
users, and from my analysis, no other virtual world technology not 
derived from the Linden/OpenSim DNA would have any benefit either. I 
have not heard any vendor outside the Linden/OpenSim sphere say that OGP 
would deliver anything of interest to them, either.

4) Various users are contributing their requirements for the evolution 
of virtual worlds, having to do with seamless travel, IP protection, the 
ability to control their own data, etc.


I was attracted to this group because I thought that the goal really was 
widespread, vendor neutral, cross-technology interoperability. It seems 
that most of the participants on the list actually aren't interested in 
that, but are interested in something much more narrow. At that point, I 
suggest the right solution is to re-charter to make the charter match 
the narrow desires, and move the broader discussion somewhere else. 
Alternatively, keep the broad charter of this group, but move the narrow 
desire somewhere else.

Trying to keep both the narrow desire, and the broad desire, in the same 
group, is a bad idea, because it leads to situations where people who 
don't care about some particular topic are still required to participate 
and endorse proposals within that topic. It also leads to discussions 
between the people with different goals, that are motivated not by 
technical requirements (what's allegedly what drives IETF standards), 
but by fundamentally incompatible basis for analysis.

Sincerely,

jw