By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,541 Members | 1,105 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,541 IT Pros & Developers. It's quick & easy.

How to Best "Lock" an Object in a Collaborative Whiteboard?

P: n/a
I'm developing a collaborative whiteboard, in which all objects
(shapes, clip art icons, etc.) are synchronized between all
participants in a session. It's working well, but I'm running into a
problem: if two people try to drag the same object at the same time,
nothing prevents them from doing so, and whichever one them lets go
first will have his move be the one that takes effect. (The other
person's client will probably crash at the moment, but that's just
from assertions.) Obviously, some form of locking is needed.

My question is not about the technical aspects _per se_, but more
about the UI aspects: I'm looking for suggestions on how best to
implement this so as not to annoy or confuse the user, while avoiding
the race conditions that tend to come with poor locking schemes.
Several possibilities have occured to me:

Before "picking up" an object, press a button to request a lock from
the server. (This is a client-server architecture, not peer-to-peer.)
If the object is not already locked, the server will grant you the
lock, and you can move it. This is probably the safest, but also the
most annoying and unintuitive, IMHO.

During the "pick up" (i.e., in the mousePressed handler), request the
lock, and until the lock is granted, block any movement of the object
(i.e., in the mouseDragged handler). This will result in the odd
behavior that the object will not move for 500ms or so, then suddenly
start.

Allow provisional motion while the lock status is being determined,
but only "commit" (during the mouseReleased handler) if the lock has
been granted; otherwise, discard the change and snap the object back
to its "official" position. This seems the closest to the way
client-server computer games (i.e., networked Quake, etc.) work, but I
don't know how well that would go over with the users.

Incidentally, both the latter options seem more race-prone than the
first (especially the last one).

Any comments on my ideas, or other suggestions for how to solve this
issue, would be much appreciated. Thanks!
--
Aaron Davies
aa**********@gmail.com.invalid
Jul 17 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
On 24 Jun 2004 07:41:14 -0700, aa**********@gmail.com (Aaron Davies)
wrote or quoted :
Before "picking up" an object, press a button to request a lock from
the server.


that will annoy your users no end. It slows down their process, and
most of the time does nothing practical.

What if you try something like this.

As soon as somebody picks something up, you send a message to the
other end to both change its colour and to lock it. The message may
arrive a little too late. The guy at the other end may gave already
picked it up.

It should then start "going electric" is someway giving a tingling
effect to hint you should let go since the other guy has a hold of it
too. In the meantime it freezes position. If one guy lets go, he sends
a message to the other, which lets him continue. Otherwise the object
is frozen until one guy lets go. Normal social rules of deference
should resolve most conflicts quickly.

If neither lets go, the system should after X seconds break the
deadlock by giving control randomly to one party or the other, or to
the higher ranking one if that is defined.

This is roughly like the difference between polled and Ethernet
collision detect protocols.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Jul 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.