On 8/29/07, Bishop, Michael W. CONTR J9C880 <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Joonas Govenius > > > > On 8/24/07, Bishop, Michael W. CONTR J9C880 > > <[EMAIL PROTECTED]> 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
