Re: [mmox] 3-world OGP interop scenario

[Charles Krinke <[e-mail]>]

Yes, I believe so. It would seem to me that defining ports, UDP vs TCP, and
the minimum possible on top of UDP and/or TCP is probably the first step. As
we move through that, leaving the maximum flexibility for evolution with
other virtual worlds whose login sequences are currently mysterious to us
seems like the safest path.

As we move forward, various virtual worlds should be able to build upon a
reasonable foundation laid brick by careful brick.

I think the current issue is defining the first set of bricks so that no one
is precluded from evolving his or her vision into the MMOX protocol as time
moves forward.

There are lots of strong opinions on how virtual worlds should operate. But,
I submit that none of that matters.

It only matters that we can move forward to allow some of the visions
expressed to become realizable while at the same time trying to not preclude
any particular vision.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Mar 18, 2009 at 9:38 AM, Morgaine <[e-mail]>wrote:

> I agree completely Charles.  Few things are more relevant to interop
> between worlds than actually "moving" (in the widest possible sense) between
> them.
>
> Teleports, direct region adjacency, gateways, wormholes, and joint
> visualization of shared spaces are all within our scope.  And to ensure that
> it doesn't fall off our radar, I would like to mention Croquet's portals
> between worlds (I don't know their actual name in Croquet) which allow you
> to see a remote world as if through a mirror with full perspective, before
> hopping through it.
>
> Our protocol work needs to support all of these concepts and more.
> Fortunately, that is easy to do, simply by focusing not on their in-world
> representations but on their underlying requirements.  These are minimal:
>
>
>    - Access to world data decoupled from any notion of an agent or avatar
>    travelling there (otherwise you would never be able to see what's on the
>    other side of a portal or boundary before travelling).
>    - World transitions decoupled from any geographical layout or topology
>    (otherwise you would never be able to teleport by landmark or address).
>
>
> We don't mandate any specific *policy* of course, so a particular world
> may allow only one particular method of entry.  The protocol itself however
> does need to provide the above two functions as *decoupled mechanisms*,
> otherwise more general movement between worlds is blocked.
>
>
> Morgaine.
>
>
>
>
>
>
>
>
>
> On Wed, Mar 18, 2009 at 3:56 PM, Charles Krinke <[e-mail]>wrote:
>
>> One thing that sticks in my mind is experiencing some of the script-based
>> HyperGrid teleports on OSGrid recently.
>>
>> Since those are using llHTTPRequest/http_response, it seems to me that
>> ensuring that whatever is adopted by this group considers enough flexibility
>> to allow folks to script the opening of gateways or wormholes or whatever to
>> other virtual worlds yet to be heard from.
>>
>> Having enough flexibility so that a script-type of language using simple
>> http calls and responses seems like a powerful and compelling feature to
>> ensure we dont loose.
>>
>> Charles Krinke
>> OpenSim Core Developer
>> OSGrid Director
>>
>> 2009/3/18 Morgaine <[e-mail]>
>>
>> On Tue, Mar 17, 2009 at 11:24 PM, Mark Lentczner <[e-mail]>wrote:
>>>
>>>>
>>>> Fundamentally - I think the scenario that Morgaine started this thread
>>>> with points to an architecture that what many people want and satisfies many
>>>> use cases.
>>>>
>>>>
>>>>
>>> That's good to hear from you, Mark.  The 3-world scenario<http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>is deliberately simple, yet it captures the central goal of interop:   to
>>> provide *users* with an interactive mashup composited out of elements
>>> taken from multiple, diverse worlds.  Everything else is a means to that
>>> end.
>>>
>>> In these few days remaining before the BoF and perhaps for a short while
>>> after that, it is a key element of our work to define the problem space
>>> (along with a few tentative solutions), since it is on that basis that a WG
>>> will be approved or denied.
>>>
>>> I believe that the given scenario defines the core of the *problem space
>>> * with good coverage, although of course not total coverage.  Very
>>> importantly, it says NOTHING about the *solution space*:  anyone who is
>>> strongly averse to adding MMOX protocol handling to their clients should
>>> note that the scenario does NOT say that A1's client has connected to B nor
>>> to C during the avatar's virtual travels to those worlds.  That would be a
>>> solution-space detail.
>>>
>>> I hope that this can be a common denominator between us all.
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Mar 17, 2009 at 11:24 PM, Mark Lentczner <[e-mail]>wrote:
>>>
>>>> Do you seriously think it's a good idea to specify all the minutiae of
>>>>> how a server and client interact, as a standard protocol?
>>>>>
>>>> Yes.
>>>> Telnet, FTP, IMAP & 2822, HTTP & HTML, XMPP, to name a few past
>>>> examples.
>>>>
>>>>  Including how GUI is tied to local and remote capabilities, how a scene
>>>>> graph is constructed and animated, how version patching is done, how user
>>>>> control is forwarded, etc?
>>>>>
>>>> Yes insofar as the semantics of the capabilities are defined, but not
>>>> the precise UI.  HTML & CSS specify quite a bit about the semantics of the
>>>> presentation - and often dictate quite precise presentation.  But browsers
>>>> are pretty free to create GUI as they see fit.
>>>> No to version patching. Updating the client is beyond the scope of the
>>>> protocol.
>>>>
>>>>  And all that work, just to be able to show up in world B instead of
>>>>> world A?
>>>>>
>>>> Yes.
>>>>
>>>>  What about objects you want to use cross worlds; are you saying you
>>>>> also want to specify the exact runtime requirements for objects (scripting
>>>>> language, physics interface, etc)?
>>>>>
>>>> Yes.
>>>> 2822 & MIME, HTML & CSS & JavaScript, ODF to name a few past examples.
>>>>
>>>>  I believe that the real enabler of interop is to be able to merge the
>>>>> simulations of different worlds
>>>>>
>>>> Ah - here we disagree.  I think this is a non-starter for the vast
>>>> majority of users and use cases. Whereas I think users really care about
>>>> using a single client, and a single virtual identity to roam the wide-open
>>>> spaces of the metaverse.
>>>>
>>>>  So, if no users want to pay money for the convenience of not having to
>>>>> install two separate clients, exactly why would any profit-seeking company
>>>>> implement a second protocol in their client?
>>>>>
>>>> Is it just a convenience that you don't have to download and run a
>>>> different browser-like client applications for your bank, for Netflix, for
>>>> Wikipedia, and for Google? I am old-enough to remember an Internet where
>>>> each of those would have been independent protocols, with independent
>>>> clients. While I as a user consider the single, universal web browser of
>>>> great value - and would pay for it (I own a retail copy of Netscape
>>>> Navigator!) - every other segment of the computer industry benefits so
>>>> greatly by this architecture, that the browser has become free.
>>>>
>>>> Fundamentally - I think the scenario that Morgaine started this thread
>>>> with points to an architecture that what many people want and satisfies many
>>>> use cases.
>>>>
>>>>        - Mark
>>>>
>>>> Mark Lentczner
>>>> Sr. Systems Architect
>>>> Technology Integration
>>>> Linden Lab
>>>>
>>>> [e-mail]
>>>>
>>>> Zero Linden
>>>> [e-mail]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> mmox mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmox
>>>>
>>>
>>>
>>> _______________________________________________
>>> mmox mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmox
>>>
>>>
>>
>>
>> --
>> Charles Krinke
>> OpenSim Core Developer
>> OSGrid Director
>>
>
>


-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director