Bug 23005

There is a branch for this in idle. It seemed to work when I tried it.

(In reply to comment #1)
> There is a branch for this in idle. It seemed to work when I tried it.

Listing rooms on big IRC servers is a bad idea: you don't get any messages other than the room list until listing finishes. On OFTC and Freenode, when I type '/list' into irssi, it tells me:

  Irssi: Doing this is not a good idea. Add -YES option to command if you really mean it

Not clear what we should do in Idle.

Some IRC networks frown upon usage of the room list feature.  In this case freenode does since it's a large network.  I think this bug should be set to won't fix personally.

is it possible to add a "-YES" option to Empathy as well?

just for reference, the branch that implements this for idle is here: http://git.collabora.co.uk/?p=user/jonathon/telepathy-idle;a=shortlog;h=refs/heads/room-list

I'm not sure what the future of this branch is. I discussed it with Sjoerd this morning but we didn't really come to a conclusion: I'd like to either merge it or abandon it before too long, so we can run Idle through a re-indenter.

Only having one room list seems broken: it's a relic from the pre-Requests spec in which we couldn't have multiple "similar" channels, and we should just delete that wording from the spec. In a protocol like IRC where you can only have one room-listing transaction open at a time, the second and subsequent channels should probably just not list anything until it's their turn?

There are two problems with indiscriminate room listing (room lists that return too many results), which jointly prompted the "/list -YES" feature in irssi:

* the server suffers from unwanted load
* you suffer because there's no way to stop the server sending out room names (possibly throttled to n lines per second where n isn't particularly large), and until it's finished, you can't receive any other message

The normal way to list channels in a dedicated IRC client like irssi is with "/list PATTERN", which lists channels matching PATTERN (which is a shell-style glob, I think?). We don't have API for this yet, only for listing every channel. We could add a method you call instead of ListRooms, ListByPattern (s), which takes an unspecified, protocol-specific pattern (a shell-glob on IRC) and lists some implementation-defined superset of that pattern. This is starting to look more like ContactSearch :-)

Sjoerd mentioned that the UI he'd ideally like to see in Empathy is "start typing and channels appear", like the live-search for contacts. One possibility would be for Idle to make ListByPattern fail until at least n characters were typed, and for Empathy to keep calling it once per keypress until it succeeded.

However, it's easy to construct pathological patterns that match a lot of channels but have enough characters in them to look relatively harmless ("******" on any server that uses shell-globs, but that's easy to avoid by not counting metacharacters, if you know all of them; "#debian-" on irc.debian.org, which is harder to avoid).

One possibility would be to have a flag for "you must specify a pattern" and have Empathy not attempt a live search, or to assume that IRC is the only thing that combines a massive user-base with a shaky protocol and have that flag be "the protocol is 'irc'".

(In reply to comment #6)
> The normal way to list channels in a dedicated IRC client like irssi is with
> "/list PATTERN", which lists channels matching PATTERN (which is a shell-style
> glob, I think?).

Actually, this isn't how this works: LIST only supports specifying a single channel name, to get its number of occupants and topic (or an error if it doesn't exist).

Some, but not all, servers run an ‘alis’ bot that you can query with.

What we should do is what irssi does to selectively enable the “not a good idea” warning: send LUSERS to the server while connecting, and look at the RPL_LUSERCHANNELS message in the reply to see how many channels there are. If that number is over some threshold, don't offer RoomList channels.

Later we could add a way to query; that could be made selectively available by looking for a user called 'alis', maybe.

(In reply to comment #7)
> (In reply to comment #6)
> > The normal way to list channels in a dedicated IRC client like irssi is with
> > "/list PATTERN", which lists channels matching PATTERN (which is a shell-style
> > glob, I think?).
> 
> Actually, this isn't how this works: LIST only supports specifying a single
> channel name, to get its number of occupants and topic (or an error if it
> doesn't exist).

To further muddy the waters, a large number of server variants actually do support listing with wildcards. Thankfully, there is a recognised detection mechanism to find out *if* it is supported: RPL_ISUPPORT (005)'s ELIST token. (I'm not certain *everything* uses this, but if it doesn't, well... bad luck for them?)

See: http://www.irc.org/tech_docs/005.html

Basically, you want to look for 'M' in ELIST's value if I remember rightly.

I snapped and updated this branch today.

It seems to work fine. It has the strange behaviour of batching the list of channels up and then emitting it all in one go (rather than emitting them as they arrive—I think the API was basically designed for IRC), which has the amusing side-effect of making Empathy freeze and peg the CPU for, ooh, half a minute when used on Freenode.

I've merged this: <http://cgit.freedesktop.org/telepathy/telepathy-idle/log/?id=04b6b07>

Having this code sitting here rotting doesn't help anyone.