[Standards-JIG] proto-JEP: SVG Whiteboarding

[Boyd Fletcher]

On 8/24/06 8:36 PM, "Joonas Govenius" <joonas.govenius at gmail.com> wrote:

> On 8/24/06, Bishop, Michael W. CONTR J9C880 <Michael.Bishop at je.jfcom.mil>
> wrote:
>> 
>> Some comments on the JEP:
>> 
>> 
>> 
>> Configure (4.6.1):  I read this as an "update" to an element.  When we
>> perform updates, we always send the entire element and simply replace or
>> fully update the element if it exists.
>> 
> 
> I felt that it was wasteful to send the whole element, especially in
> the case of long <path> elements and elements that have embedded
> base64 data like an image.
> 

but there you have  keep track of all the changes to a whiteboard which over
time can be very expensive.

Also, if a user disconnects/reconnects or joins late you have to send
considerably more data then if you just sent the current state of the
whiteboard.

>> 
>> Attribute (4.6.3):  The "attribute" section lacks the ability to specify a
>> namespace on the changes.
> 
> For now I was just using something like name="xlink:href" but perhaps
> it'd be more elegant to say something like <attribute prefix='xlink'
> name='href'/>... Is that what you meant?
> 
>> How can you "unset" or remove an attribute?
> 
> You can't ;)
> Surely the possibility should be added though. Perhaps just <attribute
> name='fill' unset='1' /> ?
> 
>> 
>> 
>> History   (4.3.4):  How does this work?  It's obvious for the entire
>> 
>> document, but how does it work for partial documents?
> 
> You can't get a partial document. I haven't seen the need so I haven't
> thought of it yet. Is it necessary? Feel free to suggest a method.
> 

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.

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.


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

> 
> "History" is probably the wrong word to use since it's not a history
> of all edits. It's something like "an undoable state of each element"
> + "all later edits to them".
> 
> The trick is how you know what state is undoable. The only method I've
> figured so far is "pinging" each of the participants, however i
> haven't included this in the JEP, it needs more thinking.

>> If not, how
>> does the user request a partial history?  If I ask for elements 5 through 7
>> and someone updated element 3, I won't have the latest version of the
>> document.  How do I know which elements I need the latest "version" of?
>> 
>> 
>> Changing the Stacking Order of the Elements (4.5.2):  We've used a more
>> fine-grained approach.  To rearrange an element's place in the tree, we use
>> a combination of "beforeId", "afterId", and "parentId".  If "beforeId" is
>> specified and "afterId" is not, the element must be the first element in a
>> group before the element with the given "beforeId".
>> 
>> If "afterId" is specified and "beforeId" is not, the element must be the
>> last element in a group after the given "afterId".  If both "afterId"
>> 
>> and "beforeId" are specified, the element must become the only element
>> between the two elements with the specified IDs.  If "parentId" is
>> specified, the element becomes the first child of that parent.  These rules
>> help with potential synchronization issues.
>> 
> 
> 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. 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?


>> 
>> Hope some of that is helpful and makes sense.
>> 
>> 
>> 
>> Michael Bishop
>> 
> 
> 
> Also,
> 
> it would probably be very useful to add an optional feature in the
> session negotiation that specifies that the versions of documents
> should be ignored (i.e. all edits are always accepted). That option
> could be used with a server component which intercepts collisions and
> sends undos to clients if necessary.
> 
> Joonas