Re: [ogpx] Tourist use case

[Morgaine <[e-mail]>]

The main reason why we're using REST and HTTP is to leverage the
infrastructure of the web and hence give ourselves massive scalability.  It
opens up the possibility of transparent caching and proxies and load
balancing and a lot of other good things, which we're going to need if
virtual worlds are going to become all-pervasive.  But to achieve that we
need to leave behind the narrow focus on sims and "free the services", which
is what REST and caps allows us.

The potential advantages really are huge, and go beyond mere caching in the
viewer.


Morgaine.



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

On Mon, Nov 2, 2009 at 11:30 PM, Carlo Wood <[e-mail]> wrote:

> This only advantage that I can see by this (the region only tells you
> that object "xyz" is at position P with orientation O), is that then
> you might be able to cache objects on the viewer.
>
> However, THAT is only possible if 'xyz' is unique (some UUID) that changes
> as soon as an object is editted in anyway, expect position and orientation
> of course (rez parameters, not part of the object).
>
> On Mon, Nov 02, 2009 at 02:05:00PM +0000, Morgaine wrote:
> > On Mon, Nov 2, 2009 at 11:49 AM, Carlo Wood <[e-mail]> wrote:
> >
> >
> >     I agree with you that information needed to see a rezzed object
> should
> >     come from the region (simulator), so -- in principle there is no
> direct
> >     reason that a viewer needs to have access to every asset server whose
> >     assets are rezzed.
> >
> >
> >
> > The region certainly needs to indicate which objects are rezzed in it ---
> it is
> > the single authority that holds that information --- there is no other
> place
> > where this information could come from in the current model.
> >
> > However, that does not mean that it has to actually hold the data, but
> merely
> > to indicate which it is so that it can be fetched.  Indeed, requiring the
> > region to hold the data or to proxy it would be really bad for protocol
> > scalability.  In any case, that's a policy choice --- our mechanism needs
> to be
> > more flexible than this in its service endpoint choices, and not require
> the
> > data to come from the region.  It is highly likely that many
> implementations
> > will aim for higher scalability than is possible to achieve by routing
> assets
> > through a sim.  Indeed, that's a primary reason for using caps for
> accessing
> > decoupled services in a REST-like manner.
> >
> > Decoupling the simulation from the storage is one of the most important
> things
> > that this protocol will achieve if we get it right.  We probably do need
> to
> > ensure that SL's existing "proxy everything" model can be expressed
> through
> > appropriate policy or deployment choices as it is likely to be a
> requirement,
> > but this should not constrain what the protocol can do under different
> policies
> > or deployment scenarios.
> >
> >
> > Morgaine.
> >
> >
> >
> >
> >
> >
> > ======================================
> >
> > On Mon, Nov 2, 2009 at 11:49 AM, Carlo Wood <[e-mail]> wrote:
> >
> >     Using common sense, I'd say:
> >
> >     * If you try to rez an object, policy comes in to determine if that
> is
> >     allowed.
> >
> >     * Once an object is rezzed, EVERYONE that is in the region (that is
> allowed
> >     to
> >      enter the region thus) can SEE that object (and interact with it).
> >
> >     I realize that it is *possible* for the region to implement a policy
> >     where it selectively shows data to some people and not to others, but
> >     I don't think we have to officially support every possible way to
> screw
> >     up shared experience in VWRAP, just because it would be possible to
> do so.
> >
> >     Compare with a protocol like SMPT: that dictates that if some email
> is
> >     received, it is required to react in one of a few given ways. There
> are
> >     other ways, but that would make the system stop functioning as
> intended,
> >     so that is Not The Idea.
> >
> >
> >     I agree with you that information needed to see a rezzed object
> should
> >     come from the region (simulator), so -- in principle there is no
> direct
> >     reason that a viewer needs to have access to every asset server whose
> >     assets are rezzed.
> >
> >
> >     An interesting question is now: what about assets that make up an
> >     avatar? Once in-world, attaching a new attachment, or changing
> clothes
> >     or shape, is just the same as rezzing of course: if the asset server
> >     allows access (by that region) than the region can buffer it and show
> >     it to everyone; otherwise attachment, or change of appearance, is
> >     disallowed.
> >     However, in the case of teleportation I think we need to act more
> >     intelligent than just black or white (allow or disallow the TP):
> >     I'm in favour of allowing the TP independent of assets being used at
> >     that moment, but instead detach assets and/or Ruth the avatar if
> >     need be (at least, give the user that option).
> >
> >     On Fri, Oct 30, 2009 at 10:23:43AM -0700, Joshua Bell wrote:
> >     > Be careful about blurring the use of "asset services" between
> "stuff in
> >     > regions" and "stuff I have". I think there is a big intersection -
> and
> >     may have
> >     > the same characteristics and/or protocols, but I also think they
> are are
> >     > distinct. I would guess that there will be asset services
> associated with
> >     both
> >     > agents and regions - off the top of my head:
> >     >
> >     > Uses of an agent-associated "asset" service:
> >     > * content to client app (inspect your inventory)
> >     > * content from client app (upload/import to inventory)
> >     > * content to region (rez something)
> >     > * content from region (buy/take something)
> >     > * content to agent (give something)
> >     > * content from agent (receive something)
> >     >
> >     > Uses of an region-associated "asset" service:
> >     > * content to client app (see the world)
> >     > * content from client app (upload/import to region)
> >     > * content to region (during teleport/region crossing)
> >     > * content from region (during teleport/region crossing)
> >     > * content to agent (buy/take something)
> >     > * content from agent (rez something)
> >     >
> >     > I'm using "asset" in quotes since that term may be overloaded.
> "Content"
> >     might
> >     > be a better term.
> >
> >     --
> >     Carlo Wood <[e-mail]>
> >     _______________________________________________
> >     ogpx mailing list
> >     [e-mail]
> >     https://www.ietf.org/mailman/listinfo/ogpx
> >
> >
>
> > _______________________________________________
> > ogpx mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ogpx
>
>
> --
> Carlo Wood <[e-mail]>
>