[jdev] Gaim -> transport

[Geoffrey Cross]

> This is what I brought up as a mere idea on the list only a couple of
> months
> ago.  The idea I got was that GAIM might be hard to wrap up into a
> transport.

Apologies for stealing the idea.  But it's actually stupidly easy.  There
were a few annoying things (like call-backs in the protocol implementations
which pop-up windows etc), but after a few hours of trawling it was trivial.

> It's probably easier to maintain than the pure C thing I proposed, but I
> wonder.  The C thing wouldn't need the SWIG stuff and could just link
> directly to the GAIM libs.  

This actually links directly to the GAIM libs too.  In fact, I said that you
need to compile GAIM, but that was a lie.  You actually only need the
libraries.  My implementation even loads the plugin libraries at runtime in
exactly the same was as GAIM itself, so if you update those you shouldn't
even need to recompile the perl package (in theory you could even reload the
libraries without restarting executable).  

> > So, I just wondered what the pros thought and whether this is something
> > which I should bother to package up and submit somewhere for more
> general
> > use?  If so, I'll bung it on a public jabberd for people to stress-test
> it
> > for a while.
> 
> Stress testing sounds like a great idea.  I was always wondering how GAIM
> would perform with 100 users on each protocol instead of 1 or 2.  This
> will
> be the test, I suppose.

Right, I'll do some final work on it and install it somewhere.  I'm
currently running it with 2 yahoo accounts, 2 MSN accounts and 2 AIM
accounts, and it's nowhere to be seen on the top process list.  I can't be
bothered to register any further accounts :).

> Maybe if the performance is taking a huge hit, there's a way to profile it
> to
> figure out where the time goes.  If it does go in the Perl interpretation,
> then we can think about porting the code.  If not, we can just panic since
> it
> will be too hard to change GAIM itself into a server. ;-)

Almost all of the time is spent inside C: the perl is pretty minimal, so I
don't think perl will be the limiting factor.  I'd expect it to be more
efficient than PyMSN which is doing most (all?) of the hard work in python.

Geoff.