On 10/24/2012 11:35 AM, Alexander Barton wrote:
- CLIENT_ID_LEN: While I respect the RFC, we had to increase this in
order to authenticate users with longer usernames in our existing account system.
This is 64 in ngIRCd. Which value are you using now? Or are you adjusting CLIENT_USER_LEN, which is 10? And how long are your user names!?
Sorry, yes, that was my mix-up; everywhere I said CLIENT_ID_LEN, read CLIENT_USER_LEN instead. We had one user whose username was exactly ten characters, so it got truncated by the terminating null, which caused PAM authentication to fail.
- MAX_RPL_LIST: We generally have around 200 channels, so the default
limit of 100 seemed a little sharp to us.
To prevent overloading the server, restricting the possoble LIST command reply seemed to be a good idea; so your user would have to use something like "/LIST nam*" to search for channels. But you are right, this could be to limiting ...
Yes, I agree having a limit is prudent and wouldn't want to remove it outright, or see it raised a lot by default. We're in kind of a special situation: our server is technically public, but meant to be used for W3C activities. So we occasionally skim the channel list to see if there are people playing on it. It's short enough that this is doable—and if it's not, that's a sign of something weird in itself. :) That's why I suggested making it configurable; I expect different administrators will want to strike different balances between network load and user convenience.
- MAX_RPL_WHO: Users who joined channels with more than 25 people in
them were getting notices in their clients about reaching this limit, and they were happy to voice their complaints about it to me. :) Apparently we're not the only ones who have dealt with this: see also http://colloquy.info/project/ticket/3251.
I think it would be best to not enforce this limit at all for channels the user requesting the list is a member of. Or?
I'd be happy with that approach too.
Best regards,