Re: [ogpx] Synchronization of gestures (was: Limits to interoperability of scripted objects)

[Carlo Wood <[e-mail]>]

My previous post was a brainstorm, and I made a view mistakes in it.
Let me try again.

Looking just at animations and sounds, we can observe that it
is impossible to deny playing a sound, and it is only possible
to deny playing an animation for ones own avatar. Nevertheless,
more in general one could think of world-manipulations, visible
to others, and requested by others, that require permissions,
the whole set of permissions can than be seen as a bit mask,
but is at the moment of no further interest. Hence, lets
concentrate for the sake of simplicity on animations.

The simplest case would be a scene with three avatars (agents,
whatever) A, B and C, where A proposes to animate B (to B)
and C is just an observer.

In the ideal situation without much lag, the protocol should
look something like this (were B/xyz and C could be a list of
agents/animations):

[A preloads animations (etc)]
A --request animation xyz of B--> simulator
simulator --A requests animation xyz --> B
[B starts preloading animations (etc)]
simulator --A requests animation xyz of B --> C
[C starts preloading animations (etc)]
B --OK--> simulator
simulator --Ready?--> A,B,C
A --Ready--> simulator
B --Ready--> simulator
C --Ready--> simulator
simulator --GO--> A,B,C
[all viewers play the animations for all avatars]


HOWEVER...

It seems better to seperate this "voting / handshaking" from whatever
is the action. If we assume an API, as morgaine proposed, that gives
us complete control over the world, then a logical step would be
to have a viewer-local scripting language that manipulates this
world (albeit locally, in this case). A given script provided by
another agent would fail if it would attempt to do something for
which it had no permission; so it should be known what permissions
a script needs before running it.

The above then can be done by replacing "animation(s)" with "running
a script". In the above case, the script would only need the
permission "animate your avatar for animation xyz".

The above then turns into:

[A preloads animation (etc)]
A         --requests to run script on B,
            needing permission "animate B with xyz"-->  simulator
simulator --A requests to run script,
            needing permissions "animate B with xyz"--> B
[B starts preloading animation (etc)]
simulator --preload animation xyz-->                    C
[C starts preloading animation (etc)]
B         --OK-->                                       simulator
simulator --script-->                                   B
simulator --Ready?-->                                   A,B,C
A         --Ready-->                                    simulator
B         --Ready-->                                    simulator
C         --Ready-->                                    simulator
simulator --GO-->                                       A,B,C
[all viewers run the script]


Now, although EVERYTHING can be implemented from here on with
"running client-side scripts" (possibly predefined, permanently
cached scripts), I'd personally add one more step to seperate
the 'voting' mechanism from 'running a script'.

I think the most general support would be to first define
that some handle means "play script needing those permissions",
and then run the voting protocol, including it's timeout
and permission-denied policies, using that handle; in that
case the voting would look like:


* Define what we vote on, and what are the timeout/permission-denied
  policies, and obtain voting-handle

* Handle preloading (tell everyone that they might need these assets).

* Ask for permissions
* Wait for permissions and/or timeouts

* Inform viewers of result about voting-handle

* Wait for preload-ready signals
* Inform viewers that everyone is ready and we have a 'go'.

* All viewers do as agreed, resulting a mutally synchronized
  experience.

On Tue, Nov 10, 2009 at 09:41:55PM +0100, Carlo Wood wrote:
> * Viewer A (or object) initiates Multi-gesture Request
>   to N (other) viewers, this involves a list of the
>   animations (UUID) to play for each of the avatars
>   involved, and sounds to play etc, and the starting
>   position in the world of each avatar.
> * Each viewer reacts with: Ok, will try; or Nope, I won't.
>   If any viewer denies the request (or times out?)
>   then the server informs all viewers that the multi-
>   animation was aborted (and why). [ An optional flag
>   could be to continue anyway, but without the avatar(s)
>   that don't want to. ]
> * Once all avatars that want to play the multi-animation
>   are known, the server sends them a message: "We have a go!"
> * All viewers that have all the needed information to
>   continue (downloaded and cached the animations, sounds etc)
>   send a message to the server: "ready!"
> * As soon as all viewers are ready (optionally, a parameter
>   of the original request includes a timeout after which
>   the delayed avatar is considered to have said "no"),
>   the server informs all viewers to start playing the
>   multi-gesture.
> 
> And YAY! finally a completely synchronized couple (and
> multi) animation, even synced with sound!
> 
> Options in case of delays (timeouts) should be:
> - Play as soon data available locally,
> - Wait till at least N, or at least those, avatars
>   are ready.
> - Abort completely if any can't play in time.
> - If someone is delayed and the rest already plays
>   the animation, then the viewer can decide to abort
>   or play the animations locally anyway, as soon as
>   they become avaiable, etc etc... All those possibilities
>   are mere bits in already existing messages, so why not.
> 
> As a side effect of this it should be possible to
> play a gesture involving animation and sound by ONE
> avatar (as are the gestures in SL now) but *synchronized*:
> everyone sees it at the same time, and the animations ARE
> synced with the sound once the start to play (unlike now,
> where the animation is played and 30 seconds later you
> hear the sound).

-- 
Carlo Wood <[e-mail]>