[IRCServices Coding] Services 5

[Mark Hetherington]

Firstly, thanks to Andrew for releasing the alpha version. Hopefully he will
not feel that he has to later remove this opportunity.

A few early questions that maybe Andrew or the Alpha team might be able to
comment on.

1) Do we have any idea on time scale for development beyond alpha? I
understand that it is a difficult question to answer given RL committments
but based on work so far and this extended open test hopefully highlighting
major issues quite quickly, might make it easier to provide an estimate.

2) Despite the warning not to run the alpha on a production network, it does
seem to be the best place to run it since it will give a much more realistic
test of the code. It is also very tempting to upgrade :) To this end, are
there specific known issues at this time with the current build that would
make it completely impractical to run on a small production network? The
"knownbugs" file does not seem to have anything specific to Services 5 and
nothing serious mentioned either way but those who have already had chance
to play with Services 5 may have a good idea of things that would make it
unsuitable for risking in a production environment.

3) At present we seem to be restricted to the mailing list for bug reporting
and discussion which makes the process qyute closed. Has there been any
thought given to providing some kind of online tracking system which would
both show what bugs are currently known and their status? Maybe something on
sourceforge or similar system would suffice.

4) I was wondering about the reasons for AJOIN being included in Services 5.
It seems to place an overhead on NickServ that has been handled by many IRC
clients for a number of years. Even clients which do not specifically
support it, but that implement perform can easily provide AJOIN
functionality. Any client supporting scripting could easily manage an AJOIN
list. A number of clients support dynamic AJOIN lists by offering to
remember hannels that a user uses on a regular basis.

Since part of the ethos behind IRC Services development is not to perform
tasks that really belong in IRCd or in clients or could be scripted, it
seems odd that firstly this system has been implemented and secondly it is
enabled in a default configuration.

Is there something specific that I am missing about this services managed
auto join list which makes it preferable to the existing client code which
already performs this task?


Anyway, back to play around with the source some more.

Mark.