[Standards] whiteboarding and shared editing

Bishop, Michael W. CONTR J9C880 Michael.Bishop at je.jfcom.mil
Wed Aug 29 17:20:41 UTC 2007


 

> -----Original Message-----
> From: standards-bounces at xmpp.org 
> [mailto:standards-bounces at xmpp.org] On Behalf Of Joonas Govenius
> Sent: Wednesday, August 29, 2007 12:01 PM
> To: XMPP Extension Discussion List
> Subject: Re: [Standards] whiteboarding and shared editing
> 
> On 8/29/07, Bishop, Michael W. CONTR J9C880 
> <Michael.Bishop at je.jfcom.mil> wrote:
> >
> > > -----Original Message-----
> > > From: standards-bounces at xmpp.org
> > > [mailto:standards-bounces at xmpp.org] On Behalf Of Joonas Govenius
> > >
> > > 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.
> >
> 
> Sure.
> 
> > >
> > > > 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 don't think so but it wouldn't really be a problem even if 
> it happened.
> 
> I think clients would pick something a little higher than the 
> highest z value (in whiteboarding at least) so that their 
> strokes come out in the "correct" order. They'd mess up the 
> ordering of their own elements too if they picked a "fairly 
> constant high value".
> 
> >  I can see two clients fighting over being first or last in a given 
> > level of the tree.
> >
> 
> With "clients fighting", do you mean that the clients would 
> automatically keep increasing/decreasing the z value or that 
> the users of the clients would repeatedly manually change the value?
> 
> The former is just inappropriate behavior from the client and 
> should probably be discouraged in the implementation notes of 
> the protocol.
> 
> The former is just stupid behavior from the users and has 
> nothing to do with the use of the "z" attribute. The users 
> can fight regardless of the mechanism used for the reordering.
>

I mean something like this:

<g1 z="1.0"/>
<g2 z="2.0"/>

If User A and User B both want to be the first child of <g1>, they'd
both (probably) pick a value like:
<a z="1.0000000000000001"/> or the smallest possible number (within
decimal precision) allowed.  Similarly, if both users want to place an
element as the LAST child of <g1>, they'd both (probably) pick a value
like:
<a z="1.9999999999999999"/> or the highest number precision allows.

I expect this to be a fairly common case in SVG; you usually append to a
given layer.  You don't draw new elements between old elements.  Also,
if 1.99...and 1.000...1 are taken, it becomes difficult to put new
elements at either end of the list.

Michael Bishop

> 
> Joonas
> 



More information about the Standards mailing list