[ogpx] Limits to interoperability of scripted objects

[Morgaine <[e-mail]>]

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.