[Standards] whiteboarding and shared editing

Joonas Govenius joonas.govenius at gmail.com
Wed Aug 29 16:01:02 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
> >
> > 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.


Joonas



More information about the Standards mailing list