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

[Carlo Wood <[e-mail]>]

On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote:
> With all due respect,  Carlo, I am finding that I disagree with your analysis.

There is no analysis.. it is something has been said before
on the list: if YOU don't want something, then that doesn't
mean there will be no need for it in the future by others.

You shouldn't take YOUR experience and desires and then say:
"we will never need this, NOBODY will EVER need this",
while it's relatively easy and simple to add the *support*
for it to the protocol!

By adding the *possibility* for viewers to wait for others,
you do not force anyone to do it different from what you
describe. But you also don't take away the possibility to
do it how other people WANT it (like me, I personally think
this is important - so thus far we have a 50% - 50% vote for
the NEED of this wait feature).

So, to be really undiplomatic blunt: who are you to deny
me this experience? While adding just a little to the protocol
we BOTH can be happy? You can do it your way, and I can do it
my way? But you say: "You don't need it" and want to remove
the possibility from the protocol so that you can do it your
way and I CANNOT do it the way I want ?!

THAT is the reasoning behind NOT leaving out rather trivial
options to the protocol. And really, this has been said on
the list before a few times imho (and no, I'm not going to
find that back).

> I have a lot of practical experience in SL getting animations
> as well as sound and textures to synchronize under a lot
> of different conditions by taking into account the client's existing
> cacheing behavior.   I'm drawing on that experience for my assertions.

I am too, and I say I need this.

> I can't think of a single reasonable use case that would *require* clients
> to hold for the slowest link.  The examples you have suggested

I can.

> don't require it to achieve the outcome you desire. 

??? Then you didn't read very well what I said.
If you want to do what I said then you *NEED* the possibility to wait
for other (some) clients (some limited time), and why not, have the
possibility to abort, or continue anyway (as you want).

Having those options you can synchronize the experience well within
lag-time, well within typing-delay time (ie, under 1 second). If you
don't wait, the playing time could run up till 30 seconds or more!

Having those options you can synchronize the experience well within
1 second AND you can do what you want: just state don't wait for anyone
and play stuff the second you get it.

[...]
> So here I'll walk through an example... the hug:
> 
> To synchronize a hug all that is needed is for the 

"all that is needed" to accomplish YOUR needs and views.
For me, I realllllly need to know when other clients are
ready too.

[...snip...]
> be longer for some clients than others.  The exact wall clock delay does not
> matter since the end user has no idea when the event was actually sent.

Yes we totally disagree here, and you are wrong: there are many other
shared experiences (typed text, and remaining movement of the avatar
before and after; not to mention voice chat) that need to be more or
less in sync with gestures; the user WILL have an idea when the event
was sent.

The wall clock DOES matter - certainly when the delay can run
up to a whole minute.

You are "right" for delays less than a second, and I argue
that we should try hard to get the shared experience synchronized
within one second IF THE USER(S) SO DESIRE.

I already gave you examples where it is notable when the delay
is larger, but I guess every example is personal. If YOU don't
care that your friends see you bolt for the door and once outside
you jump and shout "Whooohooo!", while you really intended to
first jump and shout and THEN run for the door, then well--
that is entirely your choice. Now let me, and others, have mine.

Another example, your hug: You initiate a hug request (your client
already has the needed assets or starts to download them immediately).
By the time that your partner clicks 'Ok', your viewer is ready
and immediately starts to play the hug. While hugging you say:
"Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees
that text while they don't see you hugging yet; others do however.
Because others DO, we NEED support in the protocol to know when
other clients are ready (at least, have all the needed data
cached; any other delay is too short to be bothered with-- I'm
with you on that then).

-- 
Carlo Wood <[e-mail]>