[Standards] whiteboarding and shared editing

Joonas Govenius joonas.govenius at gmail.com
Wed Aug 29 17:50:26 UTC 2007


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

Oh.

"A client can change the position of any element in its _parent's tree
of children_ by changing the value of the 'sxde:z' attribute."
(http://www.xmpp.org/extensions/inbox/sxde.html#sect-id2252315)

What I mean is that the the "z" value will never change the parent of
the element.

E.g.

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

and


<g1 z="1.0">
  <a z="-3.4"/>
</g1>
<g2 z="2.0">
</g2>

would both be perfectly valid. If you now wish to append <b/> to
<g1/>, you can do so by setting <b z='87' /> for example.

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

Firstly, see above.

Secondly, the "z" value isn't meant to be directly exposed to the user
and the clients should be smart enough not to (routinely) assign
values like 1 and 0.99... to siblings. In that case it would indeed be
difficult to add an element between the the two. However, even then,
you could just change one or both of the problematic "z" values of the
existing elements.


Joonas



More information about the Standards mailing list