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

[Carlo Wood <[e-mail]>]

On Wed, Jan 20, 2010 at 12:13:18PM +0000, Nexii Malthus wrote:
> Okay, this is a fancy idea. But I think it seems to miss the entire point.
> 
> Basically what you are doing is attempting to cope with a faulty
> system by implementing a hack on top of it. It isn't the way to go.

This idea deals ONLY with timing issues and permissions, it is completely
orthogonal to how animations are implemented.

Even if you design and use a completely different way to animate
avatars, my idea still holds (as it holds also for playing sounds,
which aren't even animations!).

The idea deals exclusively with timing and handshakes to get permission
and synchronization right. You can change the way animations work
in any way you like, this sheme will still be needed.

As I wrote in my post, I just used "animation" as example. You
can replace it with a more abstract word if you wish.

[..snip..]

I editted the first part of this code:

> > [A preloads animation/sound/whatever_data_needed (etc)]
> > A         --requests to run script on B,
> >            if the script is needing permissions, for example
> >            "animate B with xyz", it sends that request to
> >            the simulator.  Permission request-->        simulator
> > simulator --A requests to run script,
> >            needing permissions "animate B with xyz"--> B
> > [B starts preloading needed data]
> > simulator --preload data needed for xyz-->             C
> > [C starts preloading needed data]
> > 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 in a mutally synchronized
> >  experience.

-- 
Carlo Wood <[e-mail]>