ack. this was supposed to go out to the list. On Tue, Oct 13, 2009 at 1:36 PM, Meadhbh Hamrick <meadhbh.siobhan at gmail.com> wrote: > but before we go too far down the rabbit hole with solutions, can we > make sure we understand the problem domain? > > if i understand it, there's a preference that a user's avatar be > rezzable in the destination region before it is derez'd in the source > region. so in other words, we don't want to derez the user's av from > where it is until we know it can be rezzed where it's going. > > is this a fair discussion of the problem? i mean irrespective of the > proposed solutions, this is a feature of teleport that we want, right? > > assuming there is consensus on this point, we may want to gingerly > inject the requirement that the agent domain or the destination region > domain MAY want to deny the user's teleport. (remember the fuss over > adult content and underaged users?) > > it seems that this is a reasonable place to consider this topic. > however, it doesn't seem like there's radical consensus over the > question of whether it's the AD's responsibility to block underage rez > attempts in adult sims or the destination RD's responsibility or both. > so when discussing teleport, maybe we could add some verbiage like > "the AD has the option to block the teleport request here" or "the RD > has the option to block the teleport here" in flow diagrams. > > -cheers > -meadhbh > > On Tue, Oct 13, 2009 at 12:40 PM, Meadhbh Hamrick > <meadhbh.siobhan at gmail.com> wrote: >> hmm.. there were several iterations of the teleport protocol. i'm not >> really sure this is how it was deployed. and if it is, i would argue >> it _shouldn't_ be deployed this way 'cause of the trust issue. >> >> in the typical "Second Life" use case, the client trusts the agent >> domain, and the agent domain trusts region domains 1 and 2. the two >> region domains do not necessarily trust each other. or rather, there >> may be utility to a future where all region domains do not need to >> directly trust all other region domains. in the "tourist" use case, >> the agent domain can be seen as an actor of the client, so it's really >> the client who directly trusts the two region domains. but, you retain >> the benefit when you do not depend on the two region domains trusting >> each other. >> >> man. we seriously need some diagrams. >> >> -cheers >> -meadhbh/infinity >> >> On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca <vaughn.deluca at gmail.com> wrote: >>> Regarding the serialisation and passing-off of avatar data, the present TP >>> draft keeps the source region in the communication path, even *after* a >>> successful Derez and serialisation. The result from the new Rez is passed >>> via the source region back to the agent domain. >>> There might be good reasons for that path (efficiency?), but for sure it >>> complicates things if the source region is dying. >>> @Joshua >>> RD is not the same as Region, in the TP drafs its the Region(service) that >>> has the interface. >>> @Infinity, the tourist use case is not very well defined as yet (working on >>> that) but in my interpretation if will for sure specify the same constraint >>> of "no duplication of avatars". >>> -Vaughn >>> >>> On Tue, Oct 13, 2009 at 5:53 PM, Joshua Bell <josh at lindenlab.com> wrote: >>>> >>>> On Mon, Oct 12, 2009 at 10:13 PM, Morgaine >>>> <morgaine.dinova at googlemail.com> wrote: >>>>> >>>>> I suggest that the protocol define Derez and Rez as concurrent and >>>>> non-dependent operations to avoid this situation. The AD can mark R1 as >>>>> disabled for all further agent state changes --- this will provide all the >>>>> protection needed to prevent brief double-presence anomalies from being >>>>> significant. If a jammed R1 refuses to give up its hold on the avatar, then >>>>> at least the user will not suffer from it. Reaping dead simulator sessions >>>>> then becomes a problem for the region operator alone, and not for the AD, >>>>> the user, and the region as happens now. >>>> >>>> Unresponsive origin regions are an excellent use case to consider. >>>> >>>> One of the reasons that this fails today is that the origin RD maintains >>>> some amount of agent state (e.g. script state for attachments). For a >>>> sim-to-sim handoff, the origin RD must successfully transmit information >>>> either to the AD or the destination RD (or both), otherwise the user >>>> experience is poor (information is lost). Note that this needs to happen >>>> during a simple logoff/login as well. It seems to me that agent state in the >>>> AD should have ACID-ish characteristics, including the agent's current >>>> location. >>>> >>>> Given that we must be able to describe behavior of closing a client-AD >>>> connection when the RD is unresponsive (e.g. the host has dropped off the >>>> network, etc), I'd be inclined to tackle unresponsive origins in similar >>>> fashion for logout/login, region crossing, and teleport. (Which in the >>>> current drafts are indeed tackled together.) >>>> >>>> So: I would agree that the current behavior of SL is less than ideal - if >>>> the source region is unresponsive (for some TBD definition), a teleport >>>> should probably not fail. But to preserve user data (and preserve the user >>>> experience), the initial transport attempt must involve a transaction >>>> between the AD, source RD and destination RD. >>>> >>>> >>>> _______________________________________________ >>>> ogpx mailing list >>>> ogpx at ietf.org >>>> https://www.ietf.org/mailman/listinfo/ogpx >>>> >>> >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx at ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >>> >> >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.