[Standards] whiteboarding and shared editing

[Bishop, Michael W. CONTR J9C880]

> -----Original Message-----
> From: standards-bounces at xmpp.org 
> [mailto:standards-bounces at xmpp.org] On Behalf Of Joonas Govenius
> Sent: Saturday, August 25, 2007 9:12 AM
> To: XMPP Extension Discussion List
> Subject: Re: [Standards] whiteboarding and shared editing
> 
> On 8/24/07, Bishop, Michael W. CONTR J9C880 
> <Michael.Bishop at je.jfcom.mil> wrote:
> >
> > We also spent some time looking over the SXDE documentation 
> again and 
> > the proof associated with it.  How are conflicts presented to the 
> > user?  If we both edit the same element at the same time, 
> how is the 
> > user informed?  How does the client know what to assign to 
> the element?  In short, how is this problem resolved with 
> respects to UI and user feedback?
> 
> The protocol dictates that the conflicting results must be 
> undone but beyond that I don't think it's really the 
> protocols business to define how the user should be notified. 
> I guess a reasonable way would be to have some kind of a 
> "tooltip" kind of notification pop up in the area affected by 
> the collision.

No, it's not the protocol's business to do so.  However, the client has
to be able to make sense of the id/z/version/whatever and present it to
the user in a fashion they can understand.  I guess the protocol and the
client are mutually exclusive, but the client must be able to implement
the protocol in a user friendly fashion.  It seems this situation could
be solved by the client with notification as you suggested and possibly
an option to attempt to "redo" the changes.


> 
> > One thing I'm not clear on, how does your document synchronize when 
> > two elements are added at once?  Given an arbitrary parent element, 
> > what happens if I (User A) add Element A and send it to User B?  At 
> > the same time, User B adds Element B and sends it to User 
> A?  The following could occur:
> >
> > User A:  <parent><A/><B/></parent>
> > User B:  <parent><B/><A/></parent>
> >
> > I guess you can hope the z attribute is different, but is 
> it guaranteed?
> 
> Right, the primary way for determining the order is the 
> sxde:z attribute, the elements are just ordered in an ascending order.
> Perhaps a better name for the "z" attribute would be 
> "weight"; heavier elements sink.
> 
> However, like you say, it's not guaranteed that the "z" 
> attributes are different so there's a secondary (arbitrary) 
> way of determining the order of two elements with the same 
> "z" value by comparing their id's and determining which id is 
> "bigger". Doesn't really matter how "bigger" is defined but 
> you can see in 
> http://www.xmpp.org/extensions/inbox/sxde.html#glossary what 
> I though of.

Right, the z attribute mirrors SVG's rendering order.  The problem with
the z attribute is that it doesn't solve the above issue.  If clients
want to be the "first" child of a parent element or the "last" child of
a parent element, they're going to pick a fairly constant high value to
ensure this happens.  I can see two clients fighting over being first or
last in a given level of the tree.

> 
> > How are the issues implemented from a user perspective?  Do 
> you have a 
> > working implementation to look at?
> 
> There's an implementation but "working" would probably be an 
> exaggeration :)
> 
> Seriously though, I haven't had time to work on the code for 
> a long time so, although the code is in Psi svn, I don't 
> think it even compiles right now due to other changes in Psi.
> 
> 
> Joonas
>