Re: [ogpx] Teleports and protocol resilience

[Joshua Bell <josh at lindenlab.com>]

On Tue, Oct 13, 2009 at 9:55 AM, Mike Dickson <mike.dickson at hp.com> 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?