[vwrap] [wvrap] Simulation consistency

[Vaughn Deluca <[e-mail]>]

This is a question i discussed with Morgaine off-list a while ago (I
intended to send it to the list but pushed the wrong button...) I
think we need to address this problem, and decide how to deal with it.

 In Davids deployment draft, section 7.3.1.1 an overview is given van
ways to deliver content to the region. One way is only passing a
capability that allows access to (part of) the resource:
   	
	   7.3.1.1.  Content delivery models
	   A range of possible represenations can be passed to a region for
	   simulation. [...] The other end of the delivery spectrum involves passing
           only a URI or capability used to access the rendering
information and a
           collision mesh,and related data for physical simulation.
	   In such a model, the client is responsible for fetching the additional
	   information needed to render the item's visual presence from a separate
	   service.  This fetch can be done *under the credentials of the end user*
           viewing the material [my emphasis--VD] , and divorces the
simulation from
           the trust chain needed to manage content.  Any automation
is done on a
           separate host which the content creator or owner trusts,
interacting with the
           object through remoted interfaces.

 I can see the need for such a setup, however, i feel we are
unpleasantly close to a situation were the coherence of the simulation
falls apart.
In this deployment pattern the region advertises the presence of the
asset, and *some* clients will be able to get it as expected, while
-based on the arbitrary whims of the asset service- others might not.

My hope would be that after the asset server provides the region with
the capability to get the asset, it gives up control. That would mean
that if the client finds the inventory server is unwilling to serve
the content - in spire of the region saying it is present-, the client
should be able to turn around ask the *region* for the asset, (and get
is after all).

 If that is not the case, -and there are probably good reasons for the
deployment pattern as described-  shouldn't we *warn* clients that the
region might be inconsistent, so the users behind the client can vote
with their feet, (or take the risk)?

--Vaughn