Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.146]) by momotaro.dal.net (8.13.1/8.13.1/DALnet1.2) with ESMTP id n3GETlZU007035; Thu, 16 Apr 2009 07:29:48 -0700 Received: from momotaro.dal.net (localhost.localdomain [127.0.0.1]) by momotaro.dal.net (8.13.1/8.13.1/DALnet1.2) with ESMTP id n3GLp0vp003915; Thu, 16 Apr 2009 15:04:12 -0700 Received: by 10.224.67.204 with SMTP id s12mr1817643qai.306.1239892187164; Thu, 16 Apr 2009 07:29:47 -0700 (PDT) Received: by qw-out-1920.google.com with SMTP id 9so378004qwj.14 for ; Thu, 16 Apr 2009 07:29:47 -0700 (PDT) Received: from momotaro.dal.net ([66.240.218.26]) by nskntingx03p.mx.bigpond.com with ESMTP id <20090416220511.CGIA13808.nskntingx03p.mx.bigpond.com@momotaro.dal.net> for ; Thu, 16 Apr 2009 22:05:11 +0000 Received: from nskntingx03p.mx.bigpond.com ([66.240.218.26]) by nskntmtas04p.mx.bigpond.com with ESMTP id =?utf-8?q?=3C20090416220512=2EYQK?= =?utf-8?q?U12379=2Enskntmtas04p=2Emx=2Ebigpond=2Ecom=40nskntingx03p=2Emx=2E?= =?utf-8?q?bigpond=2Ecom=3E?= for ; Thu, 16 Apr 2009 22:05:12 +0000 Return-Path: From: "Vin King" Sender: To: "James Hess" Cc: "Kobi Shmueli" , References: <716eb75e0903161908p7547ca45t6ab270cfdc59f859@mail.gmail.com> <6eb799ab0904152149o1348b8e3n30cf46a018c97909@mail.gmail.com> In-Reply-To: <6eb799ab0904152149o1348b8e3n30cf46a018c97909@mail.gmail.com> Subject: Re: [DALnet-src] what about +s and +p Date: Fri, 17 Apr 2009 00:29:47 +1000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01C9BF3D.53E81A00" X-Mailer: Microsoft Office Outlook 12.0 List-Unsubscribe: , List-Help: List-Subscribe: , Thread-Index: Acm+32nfJc07c0eMTXaH87rokWJpfg== This is a multipart message in MIME format. ------=_NextPart_000_0033_01C9BF3D.53E81A00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0034_01C9BF3D.53E81A00" ------=_NextPart_001_0034_01C9BF3D.53E81A00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline /LIST is part of the RFC for IRC. The behavior it is to display is pretty well defined and understood by IRC clients. On Thu, Apr 16, 2009 at 12:49 AM, James Hess wrote: Here's a thought: 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. It's about as useful for legitimate uses as a flat '/who 0'.... Imagine if usenet had had a flat hierarchy like this. Limiting /LIST to channels with 2+ members, doesn't filter all that much, and limiting to larger channels perhaps makes /LIST even more useless, since the person may be looking for a channel that happens to have 9 members, instead of the 10 you might pick for /LIST filtering. Perhaps the LIST command should go away entirely and be replaced with a notice to check some URL for a HTTP-based search service. (Not a HTTP port opened by ircd, but a standalone module -- some service the server admin would be expected or anticipated to run as a separate process, that would have only read-only access to online IRCD data structures.) Or with some sort of category-based listing system. Where /LIST contents are approved by humans, so they meet some sort of basic standard. The average person isn't going to figure out /LIST advanced syntax, they'll try (the hard way) to find anything useful in there. 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. Possibly have /LIST show a _small_ number of highly popular channels that had to go through an extensive application process and be human-approved. _And_ a pointer to a web site for more detailed searches of channels currently online. Oh, and +p channels wouldn't be searchable in that manner. On Wed, Apr 15, 2009 at 6:06 PM, Kobi Shmueli wrote: > Adam Koeller wrote: > They're not exactly the same but perhaps it's time to have cmode +p hide the > channel completely from /list again (but still showing the channel on > /whois). > This will help channels who don't appreciate the random spambots that use > /list to find them. -- -J _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src ------=_NextPart_001_0034_01C9BF3D.53E81A00 Content-Type: text/html; boundary="===============1699009553=="; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline /LIST is part of the RFC for IRC. The behavior it is to display is pretty w= ell defined and understood by IRC clients.

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

Here'= ;s a thought:
I wonder about the scalability of /LIST =A0on 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, =A0unless they
apply some kind of filtering, =A0after they just consumed heavy
resources just to download the full listing.

It's about as useful for legitimate uses as a flat '/who 0'....=
Imagine if usenet had had a flat hierarchy like this.
Limiting /LIST to channels with 2+ members, doesn't filter all that
much, and limiting to larger channels perhaps makes /LIST even more
useless, since the person may be looking for a channel that happens to
have 9 members, instead of the 10 you might pick for /LIST filtering.

=A0Perhaps the LIST command should go away entirely and be replaced with
a notice to check some URL for a HTTP-based search service.

(Not a HTTP port opened by ircd, but a standalone module -- some
service the server admin would be expected or anticipated to run as a
separate process, that would have only read-only access to online IRCD
data structures.)

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

The average person isn't going to figure out /LIST advanced syntax,
they'll try (the hard way) to find anything useful in there.

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

Possibly have /LIST =A0 =A0show a _small_ =A0number of highly popular
channels that had to go through an extensive application process and
be human-approved.
_And_ a pointer to a web site for more detailed searches of channels
currently online.

Oh, and =A0+p =A0channels wouldn't be searchable in that manner.

On Wed, Apr 15, 2009 at 6:06 PM, Kobi Shmueli <kobi@dal.net> wrote:
> Adam Koeller wrote:
> They're not exactly the same but perhaps it's time to have cmo= de +p hide the
> channel completely from /list again (but still showing the channel on<= br> > /whois).
> This will help channels who don't appreciate the random spambots t= hat use
> /list to find them.

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

------=_NextPart_001_0034_01C9BF3D.53E81A00-- ------=_NextPart_000_0033_01C9BF3D.53E81A00 Content-Type: text/plain; name="ATT00037.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ATT00037.txt" _______________________________________________ DALnet-src mailing list DALnet-src@lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-src __________ Information from ESET Smart Security, version of virus signature= database 4014 (20090416) __________ The message was checked by ESET Smart Security. http://www.eset.com ------=_NextPart_000_0033_01C9BF3D.53E81A00--