Re: [ogpx] Tourist use case

[Morgaine <morgaine.dinova at googlemail.com>]

On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca <vaughn.deluca at gmail.com> wrote:

The second point is actually extending the SL use case beyond what is in my view needed for a basic tourist model (and that is why the post was in the mmox list).  In my view  a basic tourist use case has two main characteristics:

1.  Travel requires no prior arrangement.

        2.  Agent domains can use external asset services

I agree with this, so I have dealt separately in an earlier email with that more ambitious use case (which I'm leaving to MMOX), so that we can pursue this simpler tourist use case here.  I think you're very right to identify it as distinct.

Point 2 requires that assets services expose an interface (in the current ogp description of the AD that is not the case). 

Note that this models does *not* assumes that all assets in a services should be useable by the agent in all domains, but only that an interface is available so an asset service in one domain can be contacted by another AD. 

I think exposing the asset service interface directly is essential for meaningful interop.

I agree entirely with your suggestion that the asset service interfaces
be exposed.  Indeed, I believed this to be implicit in David's breakdown of
services anyway, as a natural consequence of service decoupling, but
it's good that you're making it explicit.

We looked at one aspect of the issue a few weeks ago with Joshua when we examined what would happen when world W1's agent A1 was in W2's RD2.  For the visual mashup of assets on the user's screen to work, the agent would need to have access to at least two asset services simultaneously, which gave us a hint of what's to come.









It's this exposing of services (asset services in particular) that is going to provide the Destination Determines [Destination] Policy principle which allows tourism.  It never existed in the original OGP, because there was no mechanism by which regions nor RDs could express their own policy, so all policy _expression_ was through the so-called trust agreements enforced at the AD which gaves access to the seed caps.  That essentially boiled down to creating ever-expanding walled garden empires that could never interoperate except through nil-trust.

In contrast, now we're solidly on the road to allowing RDs to determine their own policies through their own services, so it's a very different proposition.  As David has described, once you have multiple service providers over which individual RDs have policy control, any attempt at making policy non-local is not likely to bear much fruit.  That's the key ingredient that allows DD[D]P, and hence tourism.

And for that, the service interfaces need to be exposed.  So +1. :-)


Morgaine.







======================================

On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca <vaughn.deluca at gmail.com> wrote:

The "tourist use case" has been brought up several times, but the concept is not always used in the same way, and needs to be more precisely defined.

Morgaines original definition of the "Free Worlds Tourist use case" in http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html

mentions two characteristics:

1. Travel requires no prior arrangement.

2. Your avatar is defined by you, not by the target worlds, and it appears in those worlds with no prior arrangement. 

Point 1 is only dependent the policies of the users AD as well as that of the destination region. It is not dependent on the protocol, so in principle solved.

The second point is actually extending the SL use case beyond what is in my view needed for a basic tourist model (and that is why the post was in the mmox list).  In my view  a basic tourist use case has two main characteristics:

1.  Travel requires no prior arrangement.

        2.  Agent domains can use external asset services

Point 2 requires that assets services expose an interface (in the current ogp description of the AD that is not the case). 

Note that this models does *not* assumes that all assets in a services should be useable by the agent in all domains, but only that an interface is available so an asset service in one domain can be contacted by another AD. 

I think exposing the asset service interface directly is essential for meaningful interop.  I think it would benefit the discussion if some diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design and/or to the VWRAP wiki to document this possibility.

-Vaughn

_______________________________________________
ogpx mailing list
ogpx at ietf.org
https://www.ietf.org/mailman/listinfo/ogpx