[Standards-JIG] proto-JEP: SVG Whiteboarding

[Boyd Fletcher]

>> If you change update method to send the entire attribute then the server
>> component or other clients can just keep track of the current object tree.
>> So request the entire whiteboard will be just resend the current states
>> which will be much less than the deltas.
> 
> Changing the update method like that doesn't affect the fact that you
> need to keep history of the elements for each version that could be
> undone, in fact, you would probably end up keeping more data in the
> history; instead of individual attribute changes you would keep the
> whole element for each version.
> 

ok so this is one difference. we don't worry about undoing operations in the
protocol. We only send the current state to someone requesting it.

>> if you extend that a little bit further and has the server component inject
>> a seq number onto all the svg elements then the client can ask from every
>> starting at a particular sequence number. the seq number for an object would
>> have to be updated by the server component on each change to the object. you
>> will also have to keep track of the last action on an object so if an object
>> is deleted the client will detect that.
> 
> I think something like this is a good idea but the sequence numbers
> should be added to the <wb/> elements, or actually they're already
> identifiable with the sender-hash pair (like is done in the
> <last-edit/>). Then the client only needs to remember the last wb
> element element it received. In case it gets disconnected, it can
> request all the <wb/> elements sent since. Of course this should be
> optional because it's only doable with a server component that keeps a
> history of all the <wb/> elements (i.e. a true and complete history).
> 

ok. but must be required for server component installation. so what we would
need to is have a chart or something similar that says what is mandatory for
1-2-1, MUC-based, and server component based whiteboard. Ambiguity kills
interoperability

>> 
>>>>  Does the end user
>>>> receive a cumulative set of actions (creates/updates/deletes)?
>>> 
>>> Yes and no. The user doesn't receive any of the communative edits;
>>> they are not associated with a version in the first place. Instead,
>>> the user receives a single "create" (<new/>) which includes the result
>>> of combining all the commutative edits up to and including the version
>>> that is known to be synchronized. Deleted elements and changes to them
>>> are not included.
>> 
>> the would mean that the server component has to understand SVG which
>> complicates the server component considerably.
> 
> It doesn't need to understand SVG, it needs to understand this
> protocol and to be able to do the same processing to the XML document
> as all the clients do. I don't think that's too much to ask.
> 


>>> 
>>> I had a lengthy discussion about this with Boyd just now, I think your
>>> method's one big downside is that adding elements is not commutative
>>> with adding other elements. So if two users are trying to write a
>>> sentence at the same time for example, some strokes will be accepted
>>> from one and some from the other...
>>> 
>> 
>> however, if your case you end up with potentially confusing changes to the
>> whiteboard.
> 
> How would these changes be confusing to the user? If two users add
> elements at the same time so that they overlap, one of the elements
> will be on top of the other, they can't be in a quantum state where
> they are both on top of each other in this 2D representation ;)
> 
> But seriously, as long as all clients have these items in the same
> order I don't see the problem; and that's guaranteed in my "index"
> based system. From the user's perspective this is identical to the
> first come first serve principle.
> 


I don't agree. each client making piecemeal changes to an object can
introduce some bizarre results. which is why we send the entire svg element.
They is also why we notify the users of conflicting operations like trying
to move an object that was just deleted by someone else.


>> So the question to ask is what is the best experience for the
>> user? to get a notification of a conflict or no notification and the display
>> looking different than the user expected?
> 
> IMHO the answer is clear: showing an error everytime your new stroke
> collides with another user adding a stroke (or any element for that
> matter), would just be annoying for the user trying to for example
> write a word with strokes. The users would effectively need to take
> turns when adding elements.
> 

Our experience with taking turns is that it doesn't work in collaborative
environments. People trounce on each other all the time and don't know how
to "back-off" and retry correctly.