Implementing a Whiteboard type application.

[Ethan Blanton]

So, I looked at whiteboarding a *long* time ago, and came to a number
of conclusions ... here they are, for whatever they're worth.  (I
actually wrote the Tcl loader specifically to gain access to the Tk
canvas for the purpose of implementing vector whiteboarding.)

Sanket Agarwal spake unto us the following wisdom:
> I do realise that there are some *important* issues to handle here:
> 
>    - The encoding here shall be pivotal. We can't keep a hefty pixel by
>    pixel information to be sent( that is Suicidal + Stupid )

Agreed.  You want a vector format.  Not only does this reduce
bandwidth requirements, it makes the placed shapes editable, which I
think is key to enabling really good technical communication.

>    - A better way could be to use XML ? Which can be still verbose we might
>    look into JSON ? I was even thinking of looking into how XFIG does it ?

I personally had drafted up something xfiggish, although not exactly
using xfig syntax.  Simple statements of object position, size, etc.
Something like:

    polygon 0 1,1 5,4 3,9 # id, vertices
    circle 1 4 9,2 # id, r, center

In my mind, the important thing about the wire format is that it's
relatively simple ASCII and *not* terribly verbose; the reason being
that if you want multi-protocol compatability, you have to have a way
to stuff it into IMs with possibly rather draconian limitations.

As stpeter points out, there may be protocols with existing support
for vector whiteboarding; in that case, it would be nice to be able to
use the "right" extensions there.  However, as various protocols'
whiteboarding supports are likely to diverge in semantic behaviors,
that may be trouble.  I don't know.  Targetting XMPP's established
proposals as base functionality (assuming they are reasonable) seems
like maybe a good starting point.

>    - Again for any effective extension of the whiteboard to more complex
>    figures like *free lines* the encoding will be very important.

I think free lines are likely to suck no matter how you encode them.
;-)

Other things to think about are rate limiting and conflict resolution.
In the former case, you may get a win by batching up edits until
either a certain number have been batched (or a certain size, or
whatever) or the user is idle for a period of time.  The latter might
suck.  ;-)

> What I would like to know from the community is:
> 
>    - How important do you think the idea is, rather how much does it excite
>    you ?

I'd love to see it.  It might get me back into Pidgin from finch from
time to time.  ;-)

>    - What are the bottlenecks, I am sure amount of data to be transferred
>    will be considerable. If so what can be the remedies.

For vector formats, it need not be huge, I don't think.  Restricting
the model will help, here -- you don't want people trying to use
Pidgin in place of inkscape.  ;-)

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20100505/4a1c79f8/attachment.sig>