Re: [ogpx] Tourist use case

[Morgaine <[e-mail]>]

On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca <[e-mail]>wrote;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 <[e-mail]>wrote;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_Designand/or to the VWRAP wiki to document this possibility.
>
> -Vaughn
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>