[IRCServices Coding] Services 5 - Suggestions/Queries

[Mark Hetherington]

1) Suggestion: When a qline is set on the ircd, the error reported to the
user is formatted as follows:

Guest781361765 Erroneous Nickname: Reserved for Services

However, sqlines set in services merely report:

testsqline Erroneous Nickname: Reserved nickname

A better response would be:

testsqline Erroneous Nickname: (reason set in services)

2) Suggestion/Query: The sline modules provides a very useful central
repository for qlines/zlines etc that remove the need for individual
ircd.conf changes when a new sline is required. However, in the qline
example above, services does not seem to have added the qline to the list
used by the ircd. In the event of any downtime, this would mean that the
qlines would no longer remain in operation even though some services set
options (e.g. akills) would likely survive the downtime. I appreciate that
this maybe be largely an IRCd issue but if services were to provide a
framework for interaction with the IRCd, I am sure it should be possible to
add IRCd level support so identifying the appropriate area would be a good
first step.

3) Suggestion/Query: With the s(z)line support, I am not sure of the exact
manner in which Services determines what level of support is available in
the ircd (i.e. whether it is the appropriate protocol module or the sline
module which makes the decision and how).

I notice for Unreal, services reports in the log a lack of IP information as
being of relevance to the szline support. If this is determined by say the
protocol module, then I guess the operation is fixed by that module, but if
it is down to some sort of real time startup test, I would assume that the
Unreal "connection message" which is lacking in IP is the cause. Since this
is a relatively trivial issue to address on the IRCd, it would be useful to
have some way to have services recognise the support.

This largely depends on the method(s) services uses to determine the level
of support. If the protocol module does fix this operation, the suggestion
would be to have some type of configuration directive to override this
operation for a server modified to be more "services friendly".

If it does check the connection message format, I can safely update that
portion of code and services have access to IP addresses in the manner it
desires. A number of "tools" cite Unreal's connection message as a bug so it
may ultimately be addressed in the new version as it progresses through
beta.

However, if neither of these options is in force, then I guess I am loooking
for some long term solution to this based on how the current operation
determines support.


Mark.