*(Note that I use "LESS" generically in this post to refer to worlds of the
"shared space" model.)*

There has been no shortage of discussion about the *differences* between the
architectural models of the LESS proposal and of Second Life, and of the
impact of these differences on protocol requirements.  This has been useful,
but by itself it is not sufficient to help us arrive at any kind of
consensus about this part of the problem space, let alone the solution
space.  For that, we need to identify common ground or a common approach.

I've been looking at one of the most-often highlighted differences, namely
the *object execution model*.   This appears to be one of only 2 or 3
significant roadblocks that hold the two world models apart, so finding
either commonality or some useful symmetry could conceivably help with
interop.

*Two object execution models: inverse problems*

Jon has accurately described the merits of object execution on an object's
"home" system in LESS-type systems.  This approach benefits from proximity
of the computation to the object's local environment, and the benefits are
huge.  Not only can local objects employ all of the facilities of the local
environment, but local processing can be orders of magnitude faster than
remote execution, less starved of resources, graphically intensive and
behaviourally complex, and highly interactive with the user.  The package of
benefits is simply incontestable, and hence this is a very important
requirement.

On the other hand, object execution on an object's "home" system implies
great distance from the environmental simulation performed in a remote
shared space, and this has severe consequences.  Event response latency can
be orders of magnitude higher through remote telemetry than when the event
source and object execution are colocated.  Physics simulations are
compromised in resolution by response scatter, and compromised in speed,
complexity and event concurrency by communication bandwidth.  All of these
combine to severely limit remote environmental complexity and accuracy of
simulation, compared to remote object execution.  This is a very high price
to pay.

I know that Jon is at this point shouting "Local simulations!" with all his
might (:-), but that is no panacea.  Local simulation of a remote
environment suffers from exactly the same problems as no local simulation at
all, for a variety of reasons.  Most importantly, running simulations in
lockstep generally only works for deterministic simulations, and those are
usually not the kind we encounter in human-populated virtual worlds.  Since
the simulations are not running in lockstep, there can only be one source
for each event, either local or remote, and from this observation it is
clear that all the problems of the preceding paragraph apply here as well,
since a local simulation cannot predict events occurring in a remote
simulation.  In other words, the local simulation provides no advantage for
events arriving from the remote simulation versus a system without local
simulation, and that's why all the problems mentioned above apply.  What's
more, local simulation begins to collapse in utility as world simulations
become diverse anyway, so it is not a general solution.

I'm sure that some of the above will be disputed (correctly), but my general
point applies:  the LESS model has both advantages and disadvantages, as do
all systems.

The object execution model of Second Life is the reverse of the above,
namely object execution in the remote region, and it has the almost exactly
the same advantages and disadvantages but in reverse.  The region simulator
has a high-bandwidth and low-latency relationship with the objects it hosts
and hence provides excellent simulation performance, but objects have almost
nil relationship with the user's local environment so user integration is
almost non-existent and all the great benefits of locality are missing.  In
the OGP scheme which potentially allows Region Domains to be local, one
could obtain the high-bandwidth benefits of locality for oneself but only by
making all other participants in the region lose their locality, so it is no
solution either.

*Solution: split the behaviours and unify the models*

The key thing to observe if one wants a solution is that almost all of the
benefits of local execution are related to the *internal* behaviour of the
object (its implementation), whereas almost all of the benefits of remote
execution are related to the *external* behaviour of the object within and
reacting to its remote simulation environment.  This makes a solution easy
to identify:


   - Define objects to have separate internal and external behaviours, both
   optional.
   - External behaviour works exactly as in SL in response to environmental
   events.
   - Internal behaviour works exactly as in LESS in respect of local object
   execution.
   - If an object has both internal and external behaviours, then the two
   are connected by a telemetry event stream for remote/local behaviour
   integration.
   - Both LESS and SL systems can then gain the advantages of the other, if
   they wish.
   - Neither LESS nor SL need suffer their own respective disadvantages,
   it's their choice.
   - If LESS chooses not to implement remote object behaviour, it requires
   no system change.
   - If SL chooses not to implement local object behaviour, it requires no
   system change.
   - The object interop protocol would however need to support both, whether
   used or not.
   - Remote scripting in SL would be unchanged, except for the addition of
   local peer calls.
   - Local scripting in LESS would be unchanged, except for the addition of
   remote peer calls.
   - Since the object execution model of both is supported, one barrier to
   interop has fallen.


*Extremely simple example:*
Instead of writing very slowly and with difficulty in-world on the side of a
3D whiteboard in SL, use a local 2D canvas in the client as the local side
of the remote whiteboard object.  This could provide all the amenities of a
local drawing application, automatically perform the perspective mapping
onto the side of the whiteboard, and still do this accurately even while the
whiteboard object is being thrown around by physical events in the remote
simulation space.


I wrote this primarily to help analyse the problem space in the area of LESS
and SL object execution models, since this is currently a hard problem for
us.  The suggested solution is a byproduct of that.

To round off, I'm aware that such a solution could be problematic for
parties who may be constrained from extending their existing
implementations, since it would involve substantial work.  However, I felt
that it was worth describing this solution because of the immense gains it
can offer to both models, and because it is a solution to one specific
interop problem that we have identified and which has become an impasse.  In
addition, other MMOX parties might be able to run with it.

It is worth noting that many MMOX participants are involved in open source
VW projects, and typically in these some extra design and implementation
work is not a barrier.  Opensim or others might well find it feasible to
implement such a 2-part execution scheme, reap the benefits of this enhanced
object capability, and maybe take a lead towards interop with LESS-like
systems.

It might also spark other ideas to help us bridge the conceptual gap between
these models.


Morgaine.