Folks, I've been following this thread, and it raised a couple of ideas that I wanted to share. I also remember the days of +30k channels (years ago before the major DDoS attacks). I don't think that server resources are the main issue here, but they are [always] an issue. To accomplish both the reduction of waste every time someone issues a /list and easier filtering/searching, why not implement the following two measures?

1. Have the server cache the list (go through the hash table, say once every 15 minutes and store it). Storing the list reply should utilize less server resources than searching the hash table and going through the current match criterion sequence. When someone issues a /list command they will just get the most recent cached list. Of course we run into some latency issues with newly created channels, but I'm not sure that is a huge issue. Bottom line is that you would get some savings. I have no idea what the average is for /list-per-minute on a dal.net server, but I'd guess it is significant.

2. At some stage in the future a services agent could pull the list reply, html-ize, and serve it, auto sorting by chanserv description keywords or something else entirely. Then, as someone else mentioned you have IRCd send a message formatted in accordance with the RFC (so all of the clients can read it) directing them to the website. I know we don't want IRCd servers opening html ports, so a services agent seems to be the likely candidate for this type of operation. The only big issue that I see here is that irc and web are distinctly different protocols - do we want to have one rely on the other so much?

These are just a couple of thoughts I had. What do you guys think?

K

-----Original Message----- From: dalnet-src-bounces@lists.dal.net [mailto:dalnet-src-bounces@lists.dal.net] On Behalf Of Aaron Wiebe Sent: Thursday, April 16, 2009 12:47 PM To: dalnet-src@dal.net Cc: Kobi Shmueli Subject: Re: [DALnet-src] what about +s and +p

Greetings,

On Thu, Apr 16, 2009 at 12:49 AM, James Hess mysidia@gmail.com wrote:

I wonder about the scalability of /LIST  on todays IRC networks which have 5000+ channels at a time, it's so unreasonably large that it is pretty impractical for a human to find anything in /list,  unless they apply some kind of filtering,  after they just consumed heavy resources just to download the full listing.

There are actually functions within the LIST command to do that filtering at the server, as you mention later on....

Or with some sort of category-based listing system.    Where /LIST contents are approved by humans, so they meet some sort of basic standard.

We did discuss this one in depth a few years ago. I think we may have actually coded part of it up as well, but there were a lot of political issues with rolling it out. At that point, the ethical questions came into play as to what would qualify for the list, and how it would be administered. The conversation just died out, as I recall, but its definitely worth considering reopening. If someone were to write up a patch implementing it, I would definitely consider merging it. There would have to be some discussions within the dalnet administration about actually using it, obviously, as well as the services support to do it as well.

So I would think it better to take away the inferior tool entirely and provide a robust complete and superior replacement  mechanism  for accomplishing the goal of finding a channel.

Agreed. If you write it, I'll review it. :)

-epi _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src