[jdev] Gaim -> transport

[Trejkaz Xaoza]

On Wed, 15 Sep 2004 00:15, Geoffrey Cross wrote:
> Hi,
>
> I'm a relative newcomer to the jabber world, and this might have been
> discussed or even implemented before: if so, let me know and I'll go away
> again :).

No no, come!  Come! :-D

> Anyway, I started looking at jabber a few weeks ago and immediately
> downloaded jabberd2 without thinking.  After a lot of fussing, I've now
> managed to get PyMSN and yahoo-transport (via jcr) working.  However, it
> got me wondering (and I know this has been wondered before) why we don't
> just wrap Gaim into a transport and then we'd have all the transports
> running in one big package.

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.

The only difference with my idea is that I had suggested using JCR, which is a 
C library for writing transports... well actually, it's a C library for 
recompiling Jabberd 1.4 transports so that they run standalone.

> The advantages I can see in this approach are:
>
> 1) a single transport gateway instead of 5 or 6;
>
> 2) the Gaim guys really do know their protocols and my wrapping should be
> pretty forward compatible should the protocol implementations need to
> change;

And thus, much lower code maintenance, yes.  If this gets really stable, then 
when a problem comes along in a protocol (e.g. Yahoo change for the twelfth 
time in the year or something -- exaggeration, yes) it will literally be a 
job of "upgrade GAIM"... okay, done.  Since GAIM is entirely based around 
plugins, this should work by their design. :-)

> 1) the wrapping is done in perl (which I like, but others might not);

Perl isn't so bad.  An advantage is that it's on pretty much every system 
already (although, modules are the usual snag!)  A disadvantage is that... I 
dunno.  The language isn't as clean as Python, sure, but it's not _too_ bad.

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.  That's the only major benefit I can see with C.

> 2) building requires you to be able to build Gaim which in turn isn't
> always the easiest of tasks;

Building GAIM is easy enough... if you're on Ports or Portage. :-D
But I think even my solution would have resulted in something like this,
unless I went ahead and cloned their whole plugin framework.

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

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. ;-)

TX

-- 
'Every sufficiently advanced technology is indistinguishable from magic' - 
Arthur C Clarke
'Every sufficiently advanced magic is indistinguishable from technology' - Tom 
Graves

             Email: Trejkaz Xaoza <trejkaz at xaoza.net>
          Web site: http://xaoza.net/trejkaz/
         Jabber ID: trejkaz at jabber.xaoza.net
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20040915/d8a6f3ee/attachment-0002.pgp>