Re: [ogpx] Tourist use case

[Meadhbh Hamrick <meadhbh.siobhan at gmail.com>]

On Fri, Oct 16, 2009 at 6:35 AM, Vaughn Deluca <vaughn.deluca at gmail.com> wrote:
> Well, for what its worth, i would  :),  *Raises hand*

cool! code is always welcome. more comments to follow.

> But I see this use case in the first place as a vehicle for our thinking,
> and a way to spot implict assumptions that would limit the general usability
> of VWRAP.

sure. i kinda see the tourist model as being one end of the spectrum
and the standalone sim being the other. once you bracket the two ends
of the design space, you can start working to the middle where you'll
find cable beach and second life.

> I think that just based on good design principles a strong argument can be
> made for asset services that expose their interface, rather than keeping
> them internal to the agent domain.

absolutely! one of the things jhurliman and i have been discussing is
the concept of having a unified access protocol to reference assets in
someone's inventory AND assets that are rezzed in a simulator. having
the asset server expose an API directly would allow third party tools
to interact with and modify assets in one's inventory. obviously we
want to be very careful about this for security reasons, but i think
you could do some very compelling things (like integrate facebook and
your inventory. that way i would be able to rez all those pink
elephants people keep giving me and shoot at them in damage enabled
sims.)

and a use case for exposing the "asset service" on the simulator for
rezzed objects is it would allow them to expose a web interface like
the current http-in function in SL today. that way you could have your
online google docs presentation signal a presenter in world to change
slides so you can more easily do mixed reality presentations.

the decision to expose any or all of an asset service's interfaces to
systems outside the agent or region domains is entirely a policy
matter. i absolutely agree we should design a protocol that COULD
expose everything publicly, though i would suggest that it's unlikely
anyone would ever deploy a service without reasonable access controls.
well. not on the public intarwebz directly.

> Especially since there is nothing to prevent a configuration that works
> exactly as the current SL use case. So nothing  has to be sacrificed, yet a
> much richer set of deployment patterns becomes possible.
> -Vaughn

agreed.

any dissenting voices?

-meadhbh/infinity