On 10/25/06, Andreas Monitzer <[EMAIL PROTECTED]> wrote:
This is something I've always thought about. Using an IRC gateway for interconnecting between IRC and XMPP (which is the common way to do it right now) is pretty lame, since you need one connection per user on the XMPP side, which doesn't scale at all.
unless you connect the gateway as a component, then you only use a single connection for all users.
IRC supports server clusters, for example, freenode consists of 18 servers (plus/minus a few), which are all interconnected, and you don't notice what server you're using (unless it crashes of course). What if you would just write an IRC server that connects to this cluster, and instead of offering IRC to the user, offers an MUC service? You would only need a single connection to the IRC servers, and the XMPP protocol users wouldn't be second class. Your server is the first step into this direction, which is great!
unfortunately I think that most clusters perfer that you use the same ircd for each node, and each ircd has it's own protocol :-( There are really 3 or 4 gateways around at the moment, each attacking the problem from a different angle: (ignoring installation requirements) - PyIRCt: requires XMPP client & account, user chooses irc servers and channels - JJIGW: requires XMPP client & account, admin chooses irc servers (and channels?) - bitlbee: requires irc client & XMPP account, user chooses muc servers/components - ejabberd-ircd: requires irc client, admin chooses muc server/component -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
