Hi Yann, On Thu, Sep 11, 2008 at 11:43 AM, Yann Biancheri <[EMAIL PROTECTED]> wrote: > Hi everybody, > > We are looking at ways to implement whiteboarding over XMPP and we've found > lots of interesting proposals in the community already. We are particularly > interested in the sxe [1] and sxde [2] ones. It seems that sxde has been > written first and has leads to sxe. What we like with sxde is that it is > less verbose than sxe since you can directly add an xml element qualified > with it's namespaces, attributes, contents whereas in sxe you would have to > issue one command to create the element, and one for each of the attributes > which in the end result in a lot of xml to send in the XMPP band. On the > other hand, sxe is more recent, seems cleaner and more generic. > We were wondering if there were any other reasons such as protocol flaws > behind the move from sxde to sxe? Or if we could use one or the other > eitherway?
Your observations are correct. "SXDE" was one of the first versions of the protocol and was later renamed "SXE". Lots of other renaming and minor shuffling has also been done (e.g. 'configure' -> 'set') between the versions, but the most significant change is the change from an element-based approach to a node-based approach. There were a few reasons why I decided to shift from an element-based approach (sxde) to a node-based approach (sxe): 1. A practical limitation of the method described in the older version (sxde) is that it is impossible to make mixed content mutable (e.g. '<div>A <strong>bold</strong/ word</div>') because the text nodes are not addressable as they don't have an id. For SVG whiteboarding this might not be a huge issue but it's a pretty big limitation in general. 2. In some applications (like Inkscape) that are just a part of a tool chain and you actually need to post-process the produced XML in other tools, it's inconvenient to have extra fluff added to the elements (e.g. the 'sxde:id' attributes). 3. It seemed cleaner and more elegant to simply treat any XML node identically (instead of making a distinction between text nodes, element nodes, attribute nodes, etc.), and that did cause a significant increase in the bandwidth requirements. It would be possible to revert to some kind of hybrid between the old and the new versions where attributes for example would be addressable only indirectly through the element. However, rather than that, I thought it would be cleaner to first perfect the completely node based approach, and later add 'shortcuts' (that would map 1-to-1 to regular <new/> elements) for common operations, like adding an element node with attributes. 4. The sxe protocol could easily be mapped to a binary protocol for use over Jingle data channels for example, while doing this with sxde is much more difficult because the content is "inlined" as actual xml. This wasn't really a consideration at the time but has later occurred to me. There is also a further improvement to sxe that's not really documented anywhere yet that would make it insensitive to delivery order of messages, which would be nice particularly for Jingle based connections. I've outlined it here: http://mail.jabber.org/pipermail/sharedediting/2008-May/000005.html. Finally, I think it would be a good idea to make the protocol insensitive to receiving the same <sxe/> twice by storing some identifying information about each received <sxe/> element. If this information was also sent to new clients that join, they could easily filter out the <sxe/> elements that have already been incorporated to the document they received. This would remove practically all remaining restrictions on the underlying transport method used to deliver the <sxe/> elements. However, I admit that I haven't followed through with these updates because I decided to give all this sxe/whiteboarding stuff a break for a while. However, just last week I actually started tweaking the Psi implementation again so hopefully something useful will come out of that soon. Joonas
