Re: [ogpx] Synchronization of gestures

[Carlo Wood <[e-mail]>]

On Sat, Dec 05, 2009 at 07:00:27AM -0700, Lawson English wrote:
> All this goes back to what I just posted on the SLDEV list about
> taking initiative and coding something up. Having the ability for
> clients to talk to each other rather than some 3rd party service
> might blur the line concerning what VWRAP is supposed to be talking
> about, but, IMHO, the line is getting blurred anyway.
> 
> What's the difference between a plugin sitting on someone's desktop
> in order to augment the client in some way, and a plugin that
> actually allows clients to talk to each other directly in order to
> collectively augment them in some way? As far as I'm concerned,
> these discussions about clients talking to each other are just
> extensions totalks about what responsibilities client plugins might
> have.

For the record, nowhere I proposed to let clients talk to eachother.

It was my opinion that it is better to use the sim as trusted
middle man for all of this.

Someone sends a message to the sim, the sim sends a message to
all clients (within relevant range), and then clients reacts
back to the sim, who controls the decision making (based on
the parameters of the initial message). Once the state becomes
as requested, the sim sends again a message to all clients
to inform that that the requested state has been reached (or
one of the requested timeouts has been reached).

This means, in the case of synchronized gestures, that the
VWRAP protocol (client-server is also VWRAP no?) needs to
support some parameters for this first message that allows
a client to request the wanted strategy: a timeout per
client at least.

I think it will be sufficient to make a difference between
the following groups of clients:

1) Those participating in the multi-animation
2) Those within X meters.
3) Those within chat distance
4) Those within shout distance
5) All others

For each group, one could request a timeout as function
of distance and parcel... etc. This would result in
relative short messages (even with 100 avatars in one
place) *)

However, since all this information is already known
to the client, it's possibly better to just send a
complete list to the server with a fixed timeout
for each client (of interest).

Ie:

GESTURE_REQUEST 20.0 uuid1 -1 uuid2 10.0 uuid2 10.0 uuid3 4.0 uuid4 2.5432 uuid5 1.5281

giving timeouts in seconds, -1 means wait forever (clients not mentioned would
not be waited for). If uuid1 isn't ready within 20.0 seconds (the first parameter)
the gesture is aborted.

Those messages might be relative short too, if most viewers consider only
a small number of clients relevant (ie: only mention "friends" within chat
range).

To those thinking that this "too" complex... Really...
A computer has no problems with this "complexity" whatsoever.
All that is needed is to think it over once, document it well,
and then sit back and enjoy the flexibility and powerful
possibilities for years and years that follow.

-- 
Carlo Wood <[e-mail]>

*) Ie, I would configure my client to wait 30 seconds for
   those participating in the animation, MIN(10, 40 / distance)
   seconds for those in the same parcel and within chat range.
   25.2 / distance + 0.74 seconds for those in the same parcel
   but outside the chat range. 1.0 seconds for those outside the
   same parcel but within shout range, and not at all for those
   outside the parcel and outside the shout range.
   I'd only abort an animation when anyone participating in
   the animation would not be ready within 30 seconds, or
   when it was a gesture just for me and less than half of
   my friends within a range of 10 meter would not be ready
   within a time depending on the situation (ie, I'd configure
   the viewer to wait normally the usual time that it takes
   for anyone to download the assets, and then wait until
   at least all but one friend have the data... oh wait,
   for that I'd need to be informed about who is ready,
   when they are ready...