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 <carlo at alinoe.com>
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.