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

[Morgaine <[e-mail]>]

On Sat, Mar 14, 2009 at 7:43 PM, Jon Watte <[e-mail]> wrote:

>
> 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.



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.

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.


>
> 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.
>


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.


> <Morgaine>: 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!
>
>
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.

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.


Morgaine.








On Sat, Mar 14, 2009 at 7:43 PM, Jon Watte <[e-mail]> wrote:

> 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.NETfor 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.
>
>