[IRCServices Coding] Services 5 - Suggestions/Queries

[Finny Merrill]

On Sun, 10 Feb 2002, Mark Hetherington wrote:

> 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)

Change SQlineReason to "%s"
> 
> 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.

bahamut and unreal allow this, what are you using?
> 
> 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.

IP information is only in bahamut
> 
> 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
>