On Tue, May 09, 2006 at 01:59:48PM -0500, Bob Jamison wrote:
MenTaLguY wrote:
On Tue, 9 May 2006 10:44:31 -0700, Bryce Harrington <bryce@...961...> wrote:
Also, given our recent experience, it might be wise to do a bit more testing against test jabber servers, and make inkboard a bit more robust. Getting inkboard stable enough for us to use reliably on our own chat servers will give us confidence in recommending it for others to use.
This sounds more like an issue of the robustness of the jabber server rather than inkboard per se.
-mental
I agree. Likely Jabberd1 has always been tested with the same set of small, uniform size chat packets that everyone normally uses. Maybe it has never been given the stress of something like Inkboard before, with a rapid series of large packets. Sometimes they can be -very- large, like when an embedded image uses the xlink:href="data:stuff" attribute. Jabberd2 might be better, but who knows?
However, we should probably look at how to get Inkboard to play nicely with all Jabber servers, even the marginal and outdated ones. Like making the protocol itself be smart/efficient enough to consume less bandwidth and require fewer packets. Something like how TCP/IP uses fragmentation to traverse less-than-optimal links, or how NFS has gone through considerable evolution to make it less chatty. For example, Jabber has a streaming extension for transferring streams or large objects.
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?)
Jabber server owners would hunt us down in angry mobs with torches and pitchforks if we released Inkscape into the wild on millions of CD's in a form that wreaks havoc on their machines and networks.
Yup.
As an aside: Since all of the traffic goes through the login Jabber server no matter which conference server is hosting the MUC room, people testing Inkboard should remember to log in to the test server directly.
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.
Longer term, we'd probably want a smarter mechanism to remember servers and such, but this would at least address immediate needs, and let us put off the better but more complex solution until later.
Bryce