Subject: [ogpx] Limits to interoperability of scripted objects

From: Morgaine <[email-masked]>
Date: Tue, 27 Oct 2009 06:15:41 +0100

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.

---

From: Joshua Bell <[email-masked]>
Date: Tue, 27 Oct 2009 09:51:35 -0700

Good analysis as usual, Morgaine!

On Mon, Oct 26, 2009 at 10:15 PM, Morgaine
<[email-masked]>wrote:

>    3. Define a common scripting language and virtual machine environment
>    --- ie. a web-like Javascript approach but for regions.
A few thoughts on the above:

* Even though the Web appears to have given up on content negotiation over
HTTP, I'm still a fan and I think cross-system interop like this is a good
place for it. During Region-to-Region state transfer, you could imagine the
destination region advertising the script state types it accepts
(vendor/com.lindenlab.secondlife.lsl2mono, vendor/org.opensim.dotnetengine,
...), and the source region delivering one tagged with appropriate type. I
would imagine we'll need similar logic for static content as well - articles
of clothing could have have "prim" or "mesh" based versions, and regions may
prefer one type to another. (Although it would be more likely to have both
available on the region, and have content negotiation occur on the
region->viewer resource transfer.)

* Given the desire for "tourist" models (using the term loosely - I "live"
on my home grid, but like to visit other grids), it doesn't seem like
there's a one-size-fits-all approach (since region-to-region teleports in my
home grid and region-to-region teleports between grids utilize the same
protocol). So... this is definitely part of the protocol's mandate to sort
out.

* Combining the above two points, it implies that attachments will have to
cope with moving from areas where they have scripts running to scripts not
running (if the code/state is not compatible with the hosting region).
Fortunately, we have precedent for that. :)

* Infinity and I very briefly hand-waved about whether "portable" content
(primarily, attachments to avatars) should even be executed within the
region domain. Perhaps they should be executing in the agent domain? That's
a radical departure from how SL or OpenSim work today. (If you squint your
eyes and partition the current services, at least.) - at any rate, today
there is no script execution outside of a region. It's an intriguing idea,
but by no means complete - how such fine grained state might be updated
between domains, for example. Vehicles come to mind as another case, and
those have no clear "home base" for script execution. I suspect this is not
tractable for the first iteration of VWRAP, but I don't want to dismiss it.

* Your (3) (common scripting environment) is intriguing. Sun's Project
Wonderland uses Java (obviously...) as the common format, and (vastly
simplifying) all objects in the VW are Java objects. I'd love to learn more
from them about the challenges and successes. That said, at a protocol
level, I don't think we'd ever dictate a common environment, so going down
this road might turn into a de-facto common case of the content negotiation
(just as the Web technically allows for client-side scripting languages
other than Javascript, although they are used incredibly infrequently in
practice).

* Client-side scripts are also intriguing. If I think about what this means
in practice, it's that the client is able to manipulate the state of objects
in-world. Well, duh - that's what editing and appearance tools do! So...
that capability (pun intended!) is a requirement at the protocol level,
although I don't think we've even brushed on how to define it yet. It would
be intriguing if the protocol were such that the client could expose a
DOM-like view of the world to local scripts to observe and mutate.