Re: [ogpx] Teleports and protocol resilience

[Joshua Bell <[e-mail]>]

On Tue, Oct 13, 2009 at 9:55 AM, Mike Dickson <[e-mail]> wrote:

> On Tue, 2009-10-13 at 15:53 +0000, Joshua Bell wrote:
>
> > 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.
>
> The scripting comment is interesting re: interoperability also.  What
> does that imply if I'm going from an OpenSim instance for example which
> has additional scripting functions enabled that a SL region might not
> support.  How does the destination region determine it can run the
> scripts in attachments and that its safe to do so?
>
>
Awesome scenario to dive into.

FWIW, we've dodged the bullet on this so far with Second Life. While an SL
grid can operate in a heterogeneous state, we typically deploy new features
with forward/backward compat issues in a "disabled" state until all hosts
are updated to support the new feature, then flip a switch to enable it. In
the script case, this would mean that the ability to author/compile scripts
with new functionality would be disabled grid-wide until all hosts had been
updated. Obviously that doesn't work once agents and data are crossing
authoritative domains. :)

Can any implementers of OpenSim (or other non-SL systems using the
agent/region paradigm) describe how this is handled in those systems today?
Is there region-specific state to an agent (attachments, scripts, etc) and
how is this updated/maintained? How much effort falls on the content creator
vs. the system administrators, how aware of this is the user, etc?