[IRCServices Coding] More bugs and suggestions for Version 5.0

[Mark Hetherington]

[snip bug with suspended channels expiry)

> Do these nicknames expire on the 4.5.x branch?
> What is the output of: /ns info <nick> ALL
> This should either indicate the expiration date/time or "does 
> not expire".

I was discussing channels. I have not actually checked whether nicknames 
operate correctly. I pasted in my original email sufficient output from /cs 
info to show that the channel should have expired sometime between November 
(last used time) and today. Do not expire is not set on the channels that 
have problems. Since this database ran under 4.5.x for the whole of 
December and much of January, they do not expire under 4.5.x either as I 
said in my post. 

> Please can you confirm the setting in your config file 
> regarding default
> expiration times for suspended nicks. (both in 4.5.x and 5.x)

The nickname setting should have no effect on channel expiration so I will 
assume you mean channel. In version 5, suspended channel expiry time time 
is set to the default:
CSSuspendExpire 12d 2d. 
For version 4.5.x, I will have to extract from backup so will check this 
evening, however, I imagine it was the default setting. 

[snip guest nick limiter]
> making it possible to collide nicks off the network. The 
> current algorithm
> uses a counter and the time to generate the ID. This results 
> in a very big
> number. So basically, a new algorithm needs to be used if you 
> want to make
> the length of the guest ID shorter.

Since Services 5 already supports a smaller guest number (depending in the 
IRCds nickmax setting) in the current algorithm, I do not see how a 
configuration option requires a different algorithm for acheiving a similar 
aim. 

There are also several comments in the code suggesting why time is *not* 
used in guest nick generation. The guest nick number is generated from a 
rollover counter which is initialised with a value of rand().

[snip ID command]
> I see your point, and yes, an ID alias would be nice, but my personal
> feeling is that aliases are not a good thing (tm) :). If you 
> really want the
> ID alias - make a wrapper for the IDENTIFY function.

As I said in my post, I already have my own version of ID in each version 
of services we use. I agree that aliases in general are not a good thing as 
I said previously, I just thought this one was something that might be 
useful to have in the main distribution. After all, there is already 
SIDENTIFY which is, to all intents and purposes, an alias for IDENTIFY.


-- 
Mark.