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

[Morgaine <[e-mail]>]

On Sun, Mar 15, 2009 at 8:12 PM, Jon Watte <[e-mail]> wrote:


> Actually, I have seen the Open Sim people propose and argue for the
> "generic client" concept.



You still haven't absorbed the full implications of the 7 points given
here<http://www.ietf.org/mail-archive/web/mmox/current/msg01016.html>.
  Generic clients are completely inevitable, whether you or anyone else
likes them or not.  The reason why nobody is even bothering to make a formal
case for them is that they're already here in our midst, and sweeping back
the tide is a waste of everybody's time.  I would have hoped that is clear.



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



But we are talking about clients involved in interoperating worlds, not the
total number of clients in existence.  Since worlds of different types do
not currently interoperate, talking about the clients they use doesn't seem
very relevant.  Looking at the Opensim grids that do currently interoperate,
the majority of them work with any client of the SL family, and there are
many dozens of those (as is typical with open source software).

You can view this as client proliferation (they're all different) or as
clients coallescing and tending towards a single generic client (they're all
based on a similar model), but however you view it, both the genericity and
the proliferation are here to stay. ;-)


Morgaine.








On Sun, Mar 15, 2009 at 8:12 PM, Jon Watte <[e-mail]> wrote:

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