[IRCServices Coding] Services 5 - Suggestions/Queries

[Andrew Church]

1) SQlineReason "%s" (and your point about the examples being incosistent
   is a valid one, I'll look into it).

2) This is an ircd issue (Unreal, at least, propogates all S-lines so this
   does not occur).  If you want S-lines propogated immediately rather than
   waiting for Services to detect a violation, use ImmediatelySendSline.

3) If the protocol module provides an IP address to users.c:do_nick(), then
   IP addresses are deemed available, else they're deemed unavailable.
   Unreal doesn't send IP addresses, so you get the warning.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>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.
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding