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.
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.
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.
bob