[ogpx] Limits to interoperability of scripted objects

[Morgaine <morgaine.dinova at googlemail.com>]

There has been some mention here of script state transfer between regions on teleport over the last week.  Some caution may be needed.

VWRAP has not (yet) examined object scripting, and therefore to discuss transfer of script states has very little concrete meaning at the moment.

Unfortunately the situation is worse than merely "not yet known", because as things stand today, there is very little likelihood that script states are interoperable at all.  Script state is intrinsically linked to scripting engine implementation, and there is no proposal on the table for standardizing on a common scripting engine implementation for use by interoperating parties.

The only reason why script state is maintained across region handovers or teleports in Second Life is because all the regions use the same scripting engines.  The same is true for script state movement between regions in Opensim-based worlds.  However, you can't transfer script states between SL and Opensim regions because they use different scripting engines with different state requirements, even when using a common scripting language.

It's easy enough to conceive of a mechanism by which script states could be made portable irrespective of varying scripting engine implementations:  it just requires an extensible state descriptor unit (SDU) to be defined using a portable ADT such as LLSD, thus making state transfer portable at the protocol level.  Unfortunately this just passes the problem along to the language and scripting engine implementers who then have to map their incompatible scripting engines to a common SDU.  While this is certainly possible, it doesn't get us much closer to effective interop for script states.

While the above is bad enough, unfortunately it gets worse still.

Object scripts interact with the local simulator environment, and that environment is:

• undefined except by common practice,
• continually changing under pressure from progress and policy,
  
• semantically different in different worlds because the implementations differ,
• programmatically different because the set of callable functions differs among interoperable worlds.

What the above boils down to is that, without wholesale new design in this area, VWRAP is not going to be able to deliver continuity of script states across teleports between regions in different worlds, because neither the mechanisms nor the common environments are there to support this.

Being pragmatic about the situation, if we wish to see interop of scripting in the relatively near future, we need to find an approach that is inherently interoperable.  Here are some ideas that might be relevant to this end (these are alternatives, they don't all apply simultaneously):

1. Make script state transfer a deployment option:  both source and destination regions have to allow script state transfer for it to happen.
2. Worlds running different scripting engine implementations do not transfer state and hence scripts are initialized on teleport.
3. Define a common scripting language and virtual machine environment --- ie. a web-like _javascript_ approach but for regions.
4. If script state continuity is desired on teleports between worlds running different script engines, let such scripts run client-side.
   

Points 1 and 2 offer near-term solutions, but the functionality varies depending on the particular deployment.

Points 3 and 4 offer much broader functionality, but have a much larger design effort penalty that is probably beyond our present scope.


Morgaine.