[IRCServices Coding] More bugs and suggestions for Version 5.0

[Andrew Kempe]

Comments are inline...

> 8) Bug - either in text or operation - /cs help suspend produces the
> following information:
> -ChanServ- Unlike a forbidden channel, a suspended one does not
> -ChanServ- lose its information and will expire!
[snip]
> version 4.5.x series as well as version 5 since the channels I have
noticed
> it on were originally suspended under a version of 4.5.x and remained
> unexpired after migrating to 5.0.

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".

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)

> 9) Suggested config option to limit guest nick length. The new guest nicks
> can end up using a full 9 digit precision depending on IRCd limits which
on
> smaller networks makes them seem a little excessive. It would be nice if
> there was a configuration ption to limit this. Obviously such option would
> have to be accompanied by information on the minimum length requirement.

The ID is not a simple number. A simple counter would be too easy to predict
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.

> 10) Suggestion wrt IDENTIFY command: Although generally I have not found
> any reasons to consider or suggest aliases for existing services commands
> since they can generally be scripted client side and merely add confusion
> to the command list, I have found one "alias" that I do implement within
[snip]
> The other maybe less obvious benefit is less typing for people like myself
> that avoid scripts and automatic identification. :)

If you have one alias, more will follow. This just clutters up Services as
more people hack the aliases to their own liking. Over time it will become
more and more difficult to have a common set of commands. Support also
becomes more tricky and users more confused.

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.

Andrew