A Working Draft of a Whiteboarding JEP

Hi,

I've now made my darcs repository publically available. You
can find a
draft of the JEP from http
://mya.el-tramo.be/psi-wb/jeps/tmp_wb/wb.xml
. It now states how to send and process different element
(or
whiteboard commands) though it is not otherwise final.

It applies Mats' sync scheme to each individual SVG element
separately. Hence edits to the same element that
"cross" (as defined
in Mats' memo) are rejected but edits to different elements
are
accepted even if they cross. Also, new elements may be added
and the
elements may be raised or lowered in the tree
simultaneously.

The other alternative would be to apply Mat's scheme to the
whole
whiteboard as single entity where all modifications to the
board would
be considered "edits" and would be rejected if
they cross. Hence new
elements couldn't be added simultaneously and different
elements
couldn't be modified at the same time. I think that would
be
unreasonably strict.

My choice to apply it to elements individually brings up
three issues though.

1. Since elements may be added simultaneously, they may be
received in
different orders by different clients. Hence I've included
a statement
in the JEP that requires the clients to arrange the elements
by their
'id' attributes regardless of the order of arrival. See
the JEP draft
for details.
2. It's possible that two or more clients change the
stacking order of
an element at the same time. If they do it in the same
"direction" it
may not be possible to move it as much as the sum of these
two move
commands requires. Hence I've included a statemenet in the
JEP to move
the element as much as possible and complete the movement
when it
becomes possible. See the JEP draft for details.
3. Implementing the necessary undo stacks is more
complicated.

Those things make implementation a bit more difficult than
with other
alternative but I think the benefits are worth it.

One issue that is not taken into consideration in the JEP
yet is how
to handle clients wanting to join in the middle of a
session. Ideas
are welcome 

Another thing that I thought yesterday as I was talking to
the Dale
(Inkboard SoC '06) was if it'd be reasonable to specify
two levels or
version of the protocol. The default version 1 would only
support Tiny
SVG elements and version 2 the full SVG. Maybe there could
even be a
version 0 that would only support <path/>. The clients
would specify
which versions they support. In general, it should be easy
to support
the lower version if a client supports a higher version
simply by
disabling the user controls for drawing the "higher
version elements".

Joonas

Hi again,

On 6/22/06, Joonas Govenius <joonas.goveniusgmail.com> wrote:
> It applies Mats' sync scheme to each individual SVG
element
> separately. Hence edits to the same element that
"cross" (as defined
> in Mats' memo) are rejected but edits to different
elements are
> accepted even if they cross. Also, new elements may be
added and the
> elements may be raised or lowered in the tree
simultaneously.

Since my last post I realised  that moving an element higher
or lower
in the tree is not necessarily commutative with other moves,
additions
or removals of elements. That's why I had to change the JEP
to specify
such rules that a move is rejected if it
"crosses" another move,
addition or removal of an element. I added a
"structure version" to do
this, see the JEP for details if you're interested
(http
://mya.el-tramo.be/psi-wb/jeps/tmp_wb/wb.xml).

> 2. It's possible that two or more clients change the
stacking order of
> an element at the same time. If they do it in the same
"direction" it
> may not be possible to move it as much as the sum of
these two move
> commands requires.

This problem won't exist after the change.

Joonas