[jdev] Gaim -> transport

Stephen Pendleton spendleton at movsoftware.com
Tue Sep 14 13:34:44 CDT 2004


I think that is fine. In the past the transports have has a single
username/password login, but that isn't a rule. I suppose you could run a
seperate instance of the transport for each IM service you want to run. Each
instance would require a single username/password for the service. It does
add some flexibilty, since some people only use the MSN gateway and isn't
interested in the others. Also, if a gaim instance crashes (never happens of
course :-)), it doesn't take all the other transports along with it.

-----Original Message-----
From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On Behalf Of
Geoffrey Cross
Sent: Tuesday, September 14, 2004 2:02 PM
To: 'Jabber software development list'
Subject: RE: [jdev] Gaim -> transport



At the moment I've put separate fields for each IM and you register them all
at the same time.  As I said... I'm a XMPP virgin so there might be a nicer
way of doing it?

Geoff.


> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On 
> Behalf Of Stephen Pendleton
> Sent: 14 September 2004 18:47
> To: 'Jabber software development list'
> Subject: RE: [jdev] Gaim -> transport
> 
> This is very cool. I would be interested in seeing it on a public 
> server somewhere too. Out of curiosity, does it appear as a single 
> transport in the roster? If so, how do you register with the transport 
> to provide registration information for multiple services?
> 
> -----Original Message-----
> From: jdev-bounces at jabber.org [mailto:jdev-bounces at jabber.org] On 
> Behalf Of Geoffrey Cross
> Sent: Tuesday, September 14, 2004 11:03 AM
> To: 'Jabber software development list'
> Subject: RE: [jdev] Gaim -> transport
> 
> 
> > 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.
> 
> 
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org https://jabberstudio.org/mailman/listinfo/jdev
> 
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org https://jabberstudio.org/mailman/listinfo/jdev

_______________________________________________
jdev mailing list
jdev at jabber.org
https://jabberstudio.org/mailman/listinfo/jdev






More information about the JDev mailing list