On Tue, 9 May 2006 13:58:23 -0700, Bryce Harrington <bryce@...961...> wrote:
For what it's worth, I have a suspicion that possibly the thing that may have broken it was selecting a number of items with many nodes, cut and pasting them, and then moving them around a lot. This process seemed to generate a ton of messages, and the server bogged down trying to send that out to others in the conference room. This seems like a pretty common usage situation, so if this is what causes a lot of the traffic, perhaps there's an optimization trick that could be done? (E.g., transmitting the operation to perform on the object(s) rather than the objects themselves, and then syncing up the objects later once traffic has become quiescent again?)
Currently we simply serialize the same transaction logs we use for undo/redo, so it's just a stream of operations. As far as I know we never send objects directly. I think it's a pretty good design (and usually the most efficient), but in a few cases (like pasting a large subtree) it might be more efficient to explicitly send an XML fragment rather than a series of deltas describing its makeup.
However, in the main application we do have room to improve; often, when updating, we make a lot of wholly unnecessary changes to the XML tree. We mostly get away with it when it it's all local (although the chattiness makes some undo optimizations impossible), but obviously we pay a higher price when the whole delta has to be shoved over the network.
This gives an idea - what about if we set up our own jabber server for logging into, and put that as the default in the dialog box? This would kill two birds: It will encourage users to avoid servers other than our known good one (they'd have to do extra work to override it), plus would make life easier for testers, who currently have to re-type all the login info each time they re-login. Plus, hardcoding default text into widgets is very easy.
Yes! That's a very, very good idea.
-mental