Subject: Re: [mmox] MMOX Progress tracking (Jon Watte)

From: "zedmaster" <[email-masked]>
Date: Thu, 12 Mar 2009 09:14:25 -0000

Jon makes an excellent point here; true interop implies that there is no 
single world owner/vendor, but suggests that any world is made up from 
contributions from multiple sources.  Everything in the mail trail so far 
seems to be heading towards isolated worlds (islands) served by a common 
server-client protocol, between which a user might be able to teleport, but 
this isnt really going to help build the sort of detailed worlds that i 
think people are wanting.  All you will be able to do is hop beteween 
experiences - a bit like the "old" web model of hoppping between sites. 
Mashups have changed all that - people are now building sites which deliver 
an aggregated experience i.e. using webservices etc. they can pull together 
diverse sets of data and present something new, something the original sites 
couldnt do alone.

Imaging that I have access to some VR technology that can put immersive 
users (full motion tracking) into complex mechanical assemblies and let the 
user operate and interact with the items e.g. operate a back hoe on a JCB, 
or study the detailed assmembly instructions for an entire airliner.   I 
would like to deploy that technology to a shared world where others could 
come view my models; I wouldnt expect everyone to have access to the full 
body tracking, but i would like them to be able to walk around and touch and 
press buttons etc..

True interop to me implies that I could run the simulator which "owns" my 
mechanical entity, and I could do this wouthout needing to know or care how 
others get to view this; it doesnt matter to my simulation, as long as I get 
'standardised' inputs (telling me when someone touches something) and I get 
to send 'standard' outputs saying how the results of my simulation have 
changed.  I dont want to have to code my simulation in N different scripting 
languages for N different worlds - i just want to be able to register that 
my aeroplane is 'somewhere' in 3D space and let the worlds work out who sees 
it.

This model isnt new.  A number of the early networked VR systems (dvs, dive, 
simnet/dis)supported this federated model.  Some existing/upcoming systems 
(Sirikata is a good example) are proposing that this sort of federated 
architecture is going to be key in building really complex worlds.  It would 
be fantastic to see them contribute to this discussion.

Dare I ask the simple question here which is why not build on top of 
existing examples e.g. DIS/HLA?
If not directly extending them, learn from them and build something better.
-dirk

> ----- Original Message ----- 
>> Date: Wed, 11 Mar 2009 17:46:17 -0700
>> From: Jon Watte <[email-masked]>
>> Subject: Re: [mmox] MMOX Progress tracking
>
> .> I am claiming that a client/server protocol does not achieve virtual
>> world interop, because there is only one world involved in the 
>> connection. Thus, there is no interop between virtual worlds (plural). 
>> Thus, it's not applicable to the "vendor neutral virtual world 
>> interoperability" that is in the charter for this group, because, by 
>> necessity, only one vendor and one world is involved at a time. Let's 
>> call it scope control.
>>
>> Separately, as I keep having to repeat every week, because new people 
>> come to the list: I think that a standard client/server protocol solves a 
>> very small, uninteresting problem. It solves the problem of having to 
>> install two, three or four clients, which is a small problem. In fact, I 
>> doubt you could even get very many people to pay a single dollar for the 
>> convenience of not having to install two clients to be able to visit two 
>> different worlds (assuming versioning could be solved at all). It doesn't 
>> solve anything else -- specifically, if I want to be with person A, who 
>> is in virtual world A, and person B, who is in virtual world B, at the 
>> same time, a standardized server/client protocol makes no difference; I 
>> still have to choose one or the other. That is a problem we have now, 
>> have no good vendor neutral solution for, and need a standard for.
>>
>> If you want a standard for client/server connections that lets you stay 
>> within the same client while switching connection between different, 
>> independent worlds, just put a plugin in a browser, and write it in Flash 
>> or Java. The language and the browser is the standard; it can be done 
>> today (and has been done). I can, from my browser, easily surf on over to 
>> another site that uses a different flash/java plug-in, and connect to 
>> that other world, without losing my browser context. For all intents and 
>> purposes, this looks to the user as if "the same client" connects to 
>> those different worlds. The fact that very few implementors do that means 
>> that that kind of interop simply isn't that interesting.
>>
>> If you think it's valuable to have a client/server protocol standardized 
>> through the IETF, then you should do so within a group that is 
>> appropriately chartered. In my opinion, the MMOX charter is not 
>> appropriate for that at the current time (and, in my opinion, that's a 
>> good thing).
>>
>> Sincerely,
>>
>> jw
> .

---

From: Charles Krinke <[email-masked]>
Date: Thu, 12 Mar 2009 06:38:45 -0800

I believe the place we are at is one of partial interop between some similar
virtual worlds. And I further believe that one of the goals is to extend
this interop either in its current form or some negotiated form to other
virtual worlds.

With respect to OGP, I see that as a partial solution currently in that an
although an avatar can teleport from a Linden grid to an OpenSim grid, there
is not yet a full handoff of the client's server connections. When we can
perceive of how an avatar from a Linden grid can perform a "full handoff"
from a Linden simulator to an OpenSim simulator *and* conversely, the same
or different avatar can perform a "full handoff" from an OpenSim simulator
to a Linden simlator, then we get to the next stage.

With respect to MXP, it is currently possible, to log onto an OpenSim
simulator with either a SecondLife compatible client or an MXP compatible
client as OpenSim has implemented the MXP logic from the MXP folks. This
needs further testing.

With respect to HyperGrid, an avatar can perform a full handoff between
grids using OpenSim and work is ongoing as folks creare more logic.

So, my vision of interop is that of an avatar from one virtual world
starting on his own, home, world or region and then
teleporting/transporting/moving/<whateverWeWishToCallI> to another virtual
world where the avatar can perform chat, examine objects, interact with
other avatars and clients in a different virtual world.

And we are part way there.

The trick is to define the nuances of the logins and interconnections
currently existing for additional virtual worlds so that we can all add
support in server and client software to allow as much interoperability as
possible.

To date, the work has concentrated on virtual worlds with very similar
architecture. SecondLife and OpenSim are similar virtual worlds, but let us
not make the mistake of trying to say they are the *same* virtual world.
They are not.

How we can perform a login from an OpenSim world to a Croquet or Wonderland
or other virtual world is one of the things I believe it is to our advantage
to understand as we try to move forward in increasing interoperability.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Thu, Mar 12, 2009 at 1:14 AM, zedmaster <[email-masked]> wrote:

> This model isnt new.  A number of the early networked VR systems (dvs,
> dive, simnet/dis)supported this federated model.  Some existing/upcoming
> systems (Sirikata is a good example) are proposing that this sort of
> federated architecture is going to be key in building really complex worlds.
>  It would be fantastic to see them contribute to this discussion.
>
>>> connection. Thus, there is no interop between virtual worlds (plural). Thus,
>>> it's not applicable to the "vendor neutral virtual world interoperability"
>>> that is in the charter for this group, because, by necessity, only one
>>> vendor and one world is involved at a time. Let's call it scope control.
>>>
>>> solve anything else -- specifically, if I want to be with person A, who is
>>> in virtual world A, and person B, who is in virtual world B, at the same
>>> time, a standardized server/client protocol makes no difference; I still
>>> have to choose one or the other. That is a problem we have now, have no good
>>> vendor neutral solution for, and need a standard for.
>>>
>>> independent worlds, just put a plugin in a browser, and write it in Flash or
>>> Java. The language and the browser is the standard; it can be done today
>>> (and has been done). I can, from my browser, easily surf on over to another
>>> site that uses a different flash/java plug-in, and connect to that other
>>> world, without losing my browser context. For all intents and purposes, this
>>> looks to the user as if "the same client" connects to those different
>>> worlds. The fact that very few implementors do that means that that kind of
>>> interop simply isn't that interesting.
>>>
>>> through the IETF, then you should do so within a group that is appropriately
>>> chartered. In my opinion, the MMOX charter is not appropriate for that at
>>> the current time (and, in my opinion, that's a good thing).
>>>
>>> Sincerely,
>>>
>>> jw
>>>
>> .
>>
>
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 12 Mar 2009 08:33:37 -0700

and just to add my $0.02...

* neither MXP nor HyperGrid have been submitted as drafts, but i know  
the latter and have been told the former have seen extensive use in  
some corners of the internet, so hopefully they'll be submitted as  
drafts.

* HLA/DIS assume a level of coordination between participants that  
does not match historic use examples for non-military systems. in  
short, the "real world" appears to be ad hoc, and our objective is  
less about building worlds communicating using HLA or IEEE-1278 and  
more about giving existing worlds a fighting chance at ad hoc  
communication. we're a long way off from "the" metaverse; a single  
connected virtual world, and historically, attempts to define "the"  
protocol for "the" metaverse have failed. one might argue this is why  
you see WoW, SL, club penguin, etc. all use different protocols.

* so yes, the OGP collection of drafts are intended to be used in  
"islands," as this appears to be the current use of virtual worlds.

* at the end of the day, however, there's NOTHING that prevents an  
implementation from using LESS for server <-> server communication or  
OGP or both.

On Mar 12, 2009, at 7:38 AM, Charles Krinke wrote:

> I believe the place we are at is one of partial interop between some  
> similar virtual worlds. And I further believe that one of the goals  
> is to extend this interop either in its current form or some  
> negotiated form to other virtual worlds.
>
> With respect to OGP, I see that as a partial solution currently in  
> that an although an avatar can teleport from a Linden grid to an  
> OpenSim grid, there is not yet a full handoff of the client's server  
> connections. When we can perceive of how an avatar from a Linden  
> grid can perform a "full handoff" from a Linden simulator to an  
> OpenSim simulator *and* conversely, the same or different avatar can  
> perform a "full handoff" from an OpenSim simulator to a Linden  
> simlator, then we get to the next stage.
>
> With respect to MXP, it is currently possible, to log onto an  
> OpenSim simulator with either a SecondLife compatible client or an  
> MXP compatible client as OpenSim has implemented the MXP logic from  
> the MXP folks. This needs further testing.
>
> With respect to HyperGrid, an avatar can perform a full handoff  
> between grids using OpenSim and work is ongoing as folks creare more  
> logic.
>
> starting on his own, home, world or region and then teleporting/ 
> transporting/moving/<whateverWeWishToCallI> to another virtual world  
> where the avatar can perform chat, examine objects, interact with  
> The trick is to define the nuances of the logins and  
> interconnections currently existing for additional virtual worlds so  
> that we can all add support in server and client software to allow  
> as much interoperability as possible.
>
> To date, the work has concentrated on virtual worlds with very  
> similar architecture. SecondLife and OpenSim are similar virtual  
> worlds, but let us not make the mistake of trying to say they are  
> the *same* virtual world. They are not.
>
> How we can perform a login from an OpenSim world to a Croquet or  
> Wonderland or other virtual world is one of the things I believe it  
> is to our advantage to understand as we try to move forward in  
> increasing interoperability.
>
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
>
> Jon makes an excellent point here; true interop implies that there  
> is no single world owner/vendor, but suggests that any world is made  
> up from contributions from multiple sources.  Everything in the mail  
> trail so far seems to be heading towards isolated worlds (islands)  
> served by a common server-client protocol, between which a user  
> might be able to teleport, but this isnt really going to help build  
> the sort of detailed worlds that i think people are wanting.  All  
> you will be able to do is hop beteween experiences - a bit like the  
> "old" web model of hoppping between sites. Mashups have changed all  
> that - people are now building sites which deliver an aggregated  
> experience i.e. using webservices etc. they can pull together  
> diverse sets of data and present something new, something the  
> original sites couldnt do alone.
>
> Imaging that I have access to some VR technology that can put  
> immersive users (full motion tracking) into complex mechanical  
> assemblies and let the user operate and interact with the items e.g.  
> operate a back hoe on a JCB, or study the detailed assmembly  
> instructions for an entire airliner.   I would like to deploy that  
> technology to a shared world where others could come view my models;  
> I wouldnt expect everyone to have access to the full body tracking,  
> but i would like them to be able to walk around and touch and press  
> buttons etc..
>
> True interop to me implies that I could run the simulator which  
> "owns" my mechanical entity, and I could do this wouthout needing to  
> know or care how others get to view this; it doesnt matter to my  
> simulation, as long as I get 'standardised' inputs (telling me when  
> someone touches something) and I get to send 'standard' outputs  
> saying how the results of my simulation have changed.  I dont want  
> to have to code my simulation in N different scripting languages for  
> N different worlds - i just want to be able to register that my  
> aeroplane is 'somewhere' in 3D space and let the worlds work out who  
> sees it.
>
> This model isnt new.  A number of the early networked VR systems  
> (dvs, dive, simnet/dis)supported this federated model.  Some  
> existing/upcoming systems (Sirikata is a good example) are proposing  
> that this sort of federated architecture is going to be key in  
> building really complex worlds.  It would be fantastic to see them  
> contribute to this discussion.
>
> connection. Thus, there is no interop between virtual worlds  
> (plural). Thus, it's not applicable to the "vendor neutral virtual  
> world interoperability" that is in the charter for this group,  
> because, by necessity, only one vendor and one world is involved at  
> a time. Let's call it scope control.
>
> Separately, as I keep having to repeat every week, because new  
> people come to the list: I think that a standard client/server  
> protocol solves a very small, uninteresting problem. It solves the  
> problem of having to install two, three or four clients, which is a  
> small problem. In fact, I doubt you could even get very many people  
> to pay a single dollar for the convenience of not having to install  
> two clients to be able to visit two different worlds (assuming  
> versioning could be solved at all). It doesn't solve anything else  
> -- specifically, if I want to be with person A, who is in virtual  
> world A, and person B, who is in virtual world B, at the same time,  
> a standardized server/client protocol makes no difference; I still  
> have to choose one or the other. That is a problem we have now, have  
> no good vendor neutral solution for, and need a standard for.
>
> If you want a standard for client/server connections that lets you  
> stay within the same client while switching connection between  
> different, independent worlds, just put a plugin in a browser, and  
> write it in Flash or Java. The language and the browser is the  
> standard; it can be done today (and has been done). I can, from my  
> browser, easily surf on over to another site that uses a different  
> flash/java plug-in, and connect to that other world, without losing  
> my browser context. For all intents and purposes, this looks to the  
> user as if "the same client" connects to those different worlds. The  
> fact that very few implementors do that means that that kind of  
> If you think it's valuable to have a client/server protocol  
> standardized through the IETF, then you should do so within a group  
> that is appropriately chartered. In my opinion, the MMOX charter is  
> not appropriate for that at the current time (and, in my opinion,  
> that's a good thing).
>
> Sincerely,
>
> jw
> .
>
>

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 12 Mar 2009 14:08:47 -0700

What you envision is surely a beautiful thing.  However, calling that
"true interop" is very loaded.  An advance in interoperability at any
level, in any way, could be done, as long as it's interesting to
enough people to work on to make an IETF WG.

Beyond the terminology, I rather fear we will have too large a scope
for a successful WG, than too small a scope.

thanks,
Lisa

---

From: Jon Watte <[email-masked]>
Date: Thu, 12 Mar 2009 15:08:21 -0700

> enough people to work on to make an IETF WG.

Yes, but I believe that the charter and goals of that WG should 
adequately reflect what the WG is doing (and the people doing it). If 
the outcome of the WG work is a protocol that only Second Life and Open 
Sim with their circuit of clients is interested in, then people not 
interested in that technology sphere probably needn't be here. There's 
nothing wrong with that, if that's what you want to do -- but then that 
should be the charter. Given that that's the only thing that the Linden 
Lab people have claimed to want to work on, and actually what they have 
claimed on the list to be the reason to have started the WG in the first 
place, perhaps the easiest way to make the WG sucessful is to change the 
charter to suit the goals, with an appropriately narrow scope.

While the goals are "vendor neutral virtual world interop," however, I 
will be happy to participate, because I believe I have a lot of 
experience in the area to bring to the table, and I can also represent 
one of the many virtual world efforts that would be applicable to 
consider for such a goal. In that case, it's really a shame that we 
don't have Multiverse, Kaneva, Areae or ActiveWorlds, or any one of a 
number of other virtual world technologies represented in these 
discussions, if that is actually the goal. Perhaps you will have luck if 
you try some outreach to people like that?

Sincerely,

jw