Re: [ogpx] Tourist use case

[Joshua Bell <[e-mail]>]

On Fri, Oct 30, 2009 at 12:29 AM, Morgaine
<[e-mail]>wrote;wrote:

>
> This directly implies that asset services must be quite separate from ADs.
> Although we haven't spelled it out, clients must have access to an arbitrary
> list of asset services, because as agents travel around the VWRAP-compatible
> metaverse, the regions they visit will contain objects from an arbitrary
> number of asset service providers.
>
> *Without access to these asset services, the visited regions would not be
> visualizable at all.  And denying visualization is no business of the AD's.
>  * This makes it clear that access to asset services should not be
> mediated by the AD at all --- the AD's role should be limited to allowing or
> denying entrance to a region.  Once inside a region, it is the region that
> offers capabilities for access to the asset services of assets within the
> region.
>

After reading this a few times, I agree with the high level sentiment - but
be careful regarding the terminology, as specific wording tripped me up the
first few times through.

In the SL protocol today, clients only ever communicate with a region. It's
the region's responsibility to provide the data for what the agent sees.
This occurs both for items that would be considered aspects of the region
(chairs, buildings, trees, waterfalls) and "transient" items (other avatars
with attachments). The region exposes a data source (today, the
byte-efficient but fairly grotesque family of UDP packets) of the
description of objects (prims, textures, sourds, animations, ...) which the
client consumes.

Behind the scenes, the region may be pulling those object definitions from
an asset service, or they may be present in the region definition itself.
The client is unaware of this - it's hidden behind the services the region
exposes.

Now for the terminology bit: we can call the services the region is exposing
"asset services" but these could be quite distinct from the sorts of things
present in an agent's inventory. One phrase that's potentially confusing is
"the regions they visit will contain objects from an arbitrary number of
asset service providers" - while I agree with the high-level interpretation
of that statement, I think it paints a picture that as you're exploring a
region, the client is *necessarily* going off and making connections to a
variety of asset servers to fetch the data.

I don't think VWRAP should *preclude* that (I imagine it's only sensible for
things like textures to be referenced by URLs which could be coming off of
any old place), but my initial reading of your text was that the client
would necessarily be fetching things from external asset services. For
example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit
BarGrid you're having to ask FooGrid's asset service for the description.
Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I
don't think you're claiming that - but my first read-through came away with
that impression.)

And, of course, one can conceive of clients that implement a policy of not
trusting FooGrid for anything and wouldn't make such a connection - FooGrid
could be blacklisted by some large search company, my ISP, or perhaps my AD.


Indeed, but fortunately it hasn't been proposed that asset services be part
> of the agent service in VWRAP.  The legacy SL model of assets and
> inventories clearly doesn't apply in our extended scenarios, and the OGP
> documents never covered asset services at all, so we're defining the asset
> services and inventory model of VWRAP as we speak. :-)
>

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.