[Standards-JIG] Re: proto-JEP: SVG Whiteboarding

[Mats Bengtsson]

My comments to Joonas whiteboarding JEP version 0.0.1.

First, I think there is a fundamental difference between whiteboarding
in general, and this JEP in particular, from most (all?) other JEP protocols
due to the sync issue which is nontrivial.

There are two essential parts to such a protocol, the actual protocol
description, which Joonas has provided, and the theoretical basis for
solving the sync issue. I know that you guys are less interested in the
theoretical part, but without a solid basis with proofs of all
assumptions, we wont have an acceptable protocol.

Specific comments:

4.2: I really don't see the need for a session attribute. We already have this
notion; normal messages are just sent off as complete xml, for chat
messages we have the thread attribute which serves this purpose, and
for groupchat each room JID specifies a session.

4.3: If the initiation shall be used at all it should be placed as
a separate protocol (JEP) which handles invitiations generically and
not specifically for whiteboarding. I'm not so happy about using negotiotions
at all since we don't use them for ordinary chats or normal messages.
And groupchats we enter by free will. Perhaps the features could
instead be obtained by discoing the user. I think it is better for a client
to just accept any whiteboarding without any feature constraints and
then have resonable fallbacks for things it doesn't understand.
This is how the web works. Instead there is a great risk that we end
up in a combinatorical explosion where a client must satisfy a lot
of constraints for a whiteboard session be possible. I suggest one
single protocol with client fallbacks.

4.4+4.5: Here is where the theory kicks in. Theory is perhaps best kept
as separate documents from the JEP, but must nevertheless be placed
in some more "formal" place than my memos are.

If anyone have read my sync memo I have a fundamental assumption that all
element edits are independent of each other. This assumption is broken
in two cases as far as I can see:

  1) The stacking (display) order is all relative which makes any edits
     that affect this dependent.
  2) Grouping of elements since this is relative to a group element.

Case 1 can be given a solution if instead of a relative stacking order
and order in absolute terms is kept, which the stacking order then must
reflect. This is where the index attribute comes in.

Just as a sidenote: even the creation of new elements is not an independent
operation, surprisingly, since new elements must be placed somewhere in
the xml tree which makes element creation like raise and lower edits,
a dependent operation.

Having an absolute z-scale (the index attribute serves like one) all 
raise/lower/new operations are all commutative which is very nice.
If they were not it would be necessary to impose a locking mechanism for
the complete document, and have a document history in addition to the
element history we have now to solve the sync issue. That would be extremely
messy.
Perhaps I should eleborate on these ideas in a separate memo.

Joonas likes this z-scale because the Qt widget has methods for it.
However, keeping separate structures for one and the same thing is
error prone as all programmers know. I'd like to see some alternative
methods fail before I accept it fully.


4.5.1: "The value of the 'id' attribute MUST be of the form "m/JID/resource""
I'd like to keep the attributes as syntax free as possible and have
a separate id attribute.
 
4.6.1+2+3: Joonas likes the idea of having a single tag for everything,
like 'configure'. We have discussed this extensively and come up with many
alternative solutions which can be discussed. Most bandwidth generated the
'move' tag versus <configure transform='translate(30,20)'/>.
Perhaps a balance between his view and the "one tag for each thing" view.
Also, alternative syntax for configure is 
<configure attrname='value' attrname='value' .../> which makes the xml schema
more difficult to define but is perfectly acceptable.

One last thing: <wb xmlns='http://jabber.org/protocol/svgwb' is suggested
but isn't our Jabber custom using x-tags here?


Best Wishes,   Mats