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

[Joonas Govenius]

Oops, I sent this to Mats only when I meant to send it to the list...

---------- Forwarded message ----------
From: Joonas Govenius <joonas.govenius at gmail.com>
Date: Aug 26, 2006 7:31 PM
Subject: Re: proto-JEP: SVG Whiteboarding
To: Mats Bengtsson <matben at privat.utfors.se>


Thanks for the comments Mats.

On 8/26/06, Mats Bengtsson <matben at privat.utfors.se> wrote:
>
> 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.

I think session identifier of some kind is necessary so that the
number of sessions between two parties is not limited to one. Whether
it's the <thread/> in the <message> or a session attribute in the
<wb/> doesn't make a whole lot of difference to me.

> 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.

Some kind of initiation is certainly needed in order to get the
"state" of the whiteboard to the user wanting to join. This is the
major difference to regular chats whose functioning is not dependent
on previous messages in the same way.

The details of this delivery process brings up the question of the
value of masterless whiteboarding session (i.e. without a custom
server component). This is something I would really like to hear some
opinions on. I know that Boyd is against requiring support for them
but what about others. What is the value, if any, of having sessions
without serverside support?

> 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.

I can see the value of this and I certainly agree that something like
disco or entity capabilities should be used to find out the supported
features if that's possible. At the same time, I can see the
usefulness of recommending which features are used in some particular
session. E.g. a client can support some proprietary extension like
embedded sound clips and advertise that through disco but it can still
have "standard sessions" as long as it knows that it's not supposed to
send out those sound clip elements in that particular session.

> 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.

I agree that a separate JEP would be the best place for theory that's
not necessary for implementation.

> 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.

That's certainly not the primary reason why I like it though it's a
nice benefit :) IMHO, it's simply the most flexible and elegant
situation and doesn't require any master to decide the correct order.

BTW, calling it 'index' was probably a mistake from me as it seems to
get confused with the term index used for the ordinal number
representing the position of the element (as in 1st, 2nd, 3rd).
Perhaps just 'z' would be better.

> 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.

Of course other suggestions are welcome but I  think I'm personally
too happy with this to be able to come up with a different solution
right now.

>
> 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.

I think this is the case already, The 'id' attribute that the sentence
refers to is not the 'id' attribute of the SVG namespace but of the
whiteboarding namespace. At the moment it's done like this <new id='x'
index='y'><path .../></new> but I think it'd probably be better to do
this <new><path wb:id='x' wb:index='y' .../></new>.

As for the format of the id, the proposed format was my idea for
making sure they are unique in the session. However, I chatted with
Boyd and Michael yesterday and agreed that using GUIDs (Globally
Unique Identifiers) makes sense.

> 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.

Like we've discussed before with Mats, it'd probably be a good idea to
get some "XML expert opinions" on the different alternatives for
syntax.

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

Remko suggested that I use <wb/> instead of <x/> in the very beginning
of the summer but I don't feel strongly one way or the other...

Joonas