[Standards] whiteboarding and shared editing
Bishop, Michael W. CONTR J9C880
Michael.Bishop at je.jfcom.mil
Wed Aug 29 15:25:16 UTC 2007
> -----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.
More information about the Standards