On Monday, Feb 06 2006 17:36 Daniel Henninger wrote: > =D I figured that it was coming from PyICQ (btw, where's PyGAIM-t? > I'd be curious to look at that). I have started my work on pyGAIM-t as closed-source project. Later on I have feeled lack of time to finish it and published as GPL code within xmpppy project on SF (sf.net/projects/xmpppy/). Later on I again picked it up as closed source and now it works much more stable but I can't share code, sorry. Though I can say that published code was more-or-less stable. It just can't do subscriptions and requires X server :-D. Also you'll need to reset one or two last commits to make it compile (git reset HEAD^ or git reset HEAD^^ ).
> Just seems odd that I can't > reproduce it on my end. We never finished testing things out, btw. Yes, I know, sorry. I'm currently creating temporary logins to test with so will bug you probably today to continue testing if you are not mind. > Of course, PyGAIM-t is doing all it's work in C and I'm doing all the > work in python so that could also lead to differences in speed. Well, not so big difference. Also there is another glitch: If I send one message - then it got delayed for some random time. If I send next message - it opens gate and both messages going instantly. > Daniel > > On Feb 6, 2006, at 9:04 AM, Alexey Nezhdanov wrote: > > Got more info. > > I'm now using to transports in parallel: > > pyICQ-t and pyGAIM-t > > delays are noticed when message is going from pyICQ-t to pyGAIM-t. > > Reverse delivery is very fast. > > So as it seems the problem is on _sending_side_. That is quite > > strange. > > > > -- > > Respectfully > > Alexey Nezhdanov -- Respectfully Alexey Nezhdanov
