rename -> *.git

[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices-coding / 2005.txt

From Craig at frostycoolslug.com  Mon Apr 11 08:19:50 2005
From: Craig at frostycoolslug.com (Craig McLure)
Date: Sat Apr 30 14:03:22 2005
Subject: [IRCServices Coding] InspIRCd has reached Beta!
Message-ID: <425A956B.70103@frostycoolslug.com>

Please Note. This e-mail has been approved by Andy.

After two years of work, code built from scratch, we are pleased to 
announce the release of InspIRCd-1.0 Beta1 and Beta2 for download.

Beta2 addresses some issues found in ./configure and some fixes based on 
the initial feedback of Beta1.

I'll be honest, two years ago, i thought this project would never really 
get off the ground, let alone hit a beta release.. Thanks to the 
dedication and hard work of everyone involved, this new milestone in 
InspIRCd history has been reached.

The module API has grown in power over the years (Some people call it 
too powerful.. power is good though.. mwahaha). You can make modules to 
do pretty much anything, and if there's something you CAN'T do, find the 
requests forum, and request an addition. This allows you to make 
InspIRCd YOUR IRCd, with the features, commands, and functionality you 
want it to have.
Check the wiki for a list of currently avaliable modules.

Although we like to think of Beta1 as stable, please remember, this is 
NOT an UnrealIRCd style beta, there are still bound to be bugs (Along 
with the possibility of a crash bug here or there), the wiki contains 
full documentation on how to go about reporting these properly. To get a 
bugtracker account, please register on the forums, then use your login 
details from here.


For more details, download links, documentation etc. Please visit 
http://www.inspircd.org

Thanks.

-- 
/****************************************
  *     Craig "FrostyCoolSlug" McLure
  *       Craig@FrostyCoolSlug.com
  * InspIRCd   - http://www.inspircd.org
  * ChatSpike  - http://www.chatspike.net
  ****************************************/

From seth at gonca.net  Thu May  5 08:08:06 2005
From: seth at gonca.net (Seth)
Date: Thu May  5 09:00:42 2005
Subject: [IRCServices Coding] Nickserv register status printout
Message-ID: <001601c55185$f7b06540$0100000a@seth>

when a nick registered i don't want nickserv to write your authcode sent to 
someone@something.org because i made nickserv prit authcode to status..

For this i changed tr.l file. I put # to the begening of the lines, then i 
did "make". But it didn't change..

What must i do for nickserv not to print this message to status for both 
Turkish and English languages?


################ mail-auth module messages/responses
# General-purpose messages

#NICK_AUTH_SENT

# Nickinizin auth (tanitim) kodu %s adresine g?nderildi.




Evren 

From brain at winbot.co.uk  Thu May  5 09:25:37 2005
From: brain at winbot.co.uk (Craig Edwards)
Date: Thu May  5 09:25:18 2005
Subject: [IRCServices Coding] Nickserv register status printout
In-Reply-To: <001601c55185$f7b06540$0100000a@seth>
References: <001601c55185$f7b06540$0100000a@seth>
Message-ID: <427A4901.2050100@winbot.co.uk>

did you forget 'make install' to move the new files into your build dir 
and build the language files?

Seth wrote:
> when a nick registered i don't want nickserv to write your authcode sent 
> to someone@something.org because i made nickserv prit authcode to status..
> 
> For this i changed tr.l file. I put # to the begening of the lines, then 
> i did "make". But it didn't change..
> 
> What must i do for nickserv not to print this message to status for both 
> Turkish and English languages?
> 
> 
> ################ mail-auth module messages/responses
> # General-purpose messages
> 
> #NICK_AUTH_SENT
> 
> # Nickinizin auth (tanitim) kodu %s adresine g?nderildi.
> 
> 
> 
> 
> Evren
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> 

-- 
WinBot IRC client developer: http://www.winbot.co.uk
ChatSpike - The users network: http://www.chatspike.net
InspIRCd - Modular IRC server: http://www.inspircd.org
Online RPG Developer: http://www.ssod.org
--
From achurch at achurch.org  Fri May  6 02:41:47 2005
From: achurch at achurch.org (Andrew Church)
Date: Thu May  5 10:42:51 2005
Subject: [IRCServices Coding] Nickserv register status printout
In-Reply-To: <001601c55185$f7b06540$0100000a@seth>
Message-ID: <427a5b13.43265@msgid.achurch.org>

>What must i do for nickserv not to print this message to status for both 
>Turkish and English languages?

     This has nothing to do with the language files; you need to modify the
source to not send the message (modules/nickserv/mail-auth.c).

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From seth at gonca.net  Thu May  5 10:56:29 2005
From: seth at gonca.net (Seth)
Date: Thu May  5 10:56:31 2005
Subject: [IRCServices Coding] Nickserv register status printout
References: <427a5b13.43265@msgid.achurch.org>
Message-ID: <006401c5519b$c459b000$0100000a@seth>

Well, thanks, but which part of that file must i change/delete exactly?

Thanks..


Evren



----- Original Message ----- 
From: "Andrew Church" <achurch@achurch.org>
To: <ircservices-coding@ircservices.esper.net>
Sent: Thursday, May 05, 2005 8:41 PM
Subject: Re: [IRCServices Coding] Nickserv register status printout


> >What must i do for nickserv not to print this message to status for both
>>Turkish and English languages?
>
>     This has nothing to do with the language files; you need to modify the
> source to not send the message (modules/nickserv/mail-auth.c).
>
>  --Andrew Church
>    achurch@achurch.org
>    http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding 

From achurch at achurch.org  Fri May  6 09:47:28 2005
From: achurch at achurch.org (Andrew Church)
Date: Thu May  5 17:49:01 2005
Subject: [IRCServices Coding] Nickserv register status printout
In-Reply-To: <006401c5519b$c459b000$0100000a@seth>
Message-ID: <427abeee.43401@msgid.achurch.org>

     Read the source and figure it out yourself, or ask someone else for
help.  As a rule, I don't offer assistance with modifying Services.

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

>Well, thanks, but which part of that file must i change/delete exactly?
>
>Thanks..
>
>
>Evren
>
>
>
>----- Original Message ----- 
>From: "Andrew Church" <achurch@achurch.org>
>To: <ircservices-coding@ircservices.esper.net>
>Sent: Thursday, May 05, 2005 8:41 PM
>Subject: Re: [IRCServices Coding] Nickserv register status printout
>
>
>> >What must i do for nickserv not to print this message to status for both
>>>Turkish and English languages?
>>
>>     This has nothing to do with the language files; you need to modify the
>> source to not send the message (modules/nickserv/mail-auth.c).
>>
>>  --Andrew Church
>>    achurch@achurch.org
>>    http://achurch.org/
>> ------------------------------------------------------------------
>> To unsubscribe or change your subscription options, visit:
>> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding 
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From brain at winbot.co.uk  Sat May  7 14:04:16 2005
From: brain at winbot.co.uk (Craig Edwards)
Date: Sat May  7 14:04:03 2005
Subject: [IRCServices Coding] send_cmd in non-protocol modules
In-Reply-To: <427ad262.45651@msgid.achurch.org>
References: <427ad262.45651@msgid.achurch.org>
Message-ID: <427D2D50.8070400@winbot.co.uk>

Hi everyone

As an ircd developer ive noticed an annoying issue with ircservices. 
IRCServices 5 is a powerful technologically superior program, but, it 
has one tiny flaw which i will detail here (it isnt too difficult to fix 
actually):

IRCServices 5 has protocol modules which allow it to connect to many 
different kinds of ircds easily. Great idea. However, the core blatantly 
uses send_cmd, and makes assumptions about the format of specific 
commands, which in parts, makes protocol modules practically useless. 
Lets take for example two ircds, one very common and very well known, 
ircu, and one not so common and not so well known, inspircd. Both of 
these ircds use non-standard server to server communication, which is 
tokenized by default and *cannot* be sent untokenized. IRCServices, when 
sending a notice, has a send_cmd in send.c, which does this:

send_cmd(source, "NOTICE %s :%s", dest, buf);

This is fine for ircds which follow RFC1459 to the letter, but as we all 
know, many (read most) ircds do not. This means, that unless an ircd 
supports the RFC *to the letter*, ircservices cannot support it, without 
some major kludges (e.g. rewriting input strings). If you send this 
command to IRCu, using the P10 protocol, IRCu will disconnect your 
services server for sending invalid commands (IRCu once authenticated 
has no idea what NOTICE is, only the *token* for NOTICE). InspIRCd will 
simply drop the command. I'm sure there are other ircds out there that 
will have similar problems.

There are many other commands which are 'assumed' in this manner in the 
core, some being:

PRIVMSG, SVSMODE, SVS2MODE, PING, PONG, VERSION

In my own IRCd ive managed to kludge around this by having the uplink 
rewrite said messages to valid tokens before theyre processed, but IRCu 
and other token-only ircds are not able to do this.

Now, this email is *not a flame or a rant*, i love ircservices, and i 
would love to see this situation improved. If i must submit patches to 
andy myself to do so, i will (i have the spare time to do it) but here 
is what i suggest, wether its me or someone else that codes it:

These functions (notice, privmsg, mode, ping etc) should be moved into 
the protocol modules, e.g. move the notice() function to the protocol 
module, move the svsmode() function to the protocol module, etc. This is 
the way other services packages (such as anope) do it. Right now, there 
is something you can do (which is kludgy) which allows you to 'override' 
the default functions in the core, but if you use this kludge, you 
cannot compile ircservices statically (which probably isnt good).

So, theres my issue, and my recommended way of fixing it :-)

Thanks for reading all this, and please let me know what you think,

Brain
From achurch at achurch.org  Sun May  8 06:47:32 2005
From: achurch at achurch.org (Andrew Church)
Date: Sat May  7 14:51:50 2005
Subject: [IRCServices Coding] send_cmd in non-protocol modules
In-Reply-To: <427D2D50.8070400@winbot.co.uk>
Message-ID: <427d386f.46347@msgid.achurch.org>

>IRCServices 5 has protocol modules which allow it to connect to many 
>different kinds of ircds easily. Great idea. However, the core blatantly 
>uses send_cmd, and makes assumptions about the format of specific 
>commands,

     This is by design.  The only reason for protocol modules in the first
place is to kludge around variations in what ought to be a standard.  If
you have an ircd that's so bizarre it can't even understand a NOTICE
message, then Services won't support it.  Sorry, but I don't have the time
or interest to deal with such software.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From brain at winbot.co.uk  Sat May  7 15:01:18 2005
From: brain at winbot.co.uk (Craig Edwards)
Date: Sat May  7 15:01:00 2005
Subject: [IRCServices Coding] send_cmd in non-protocol modules
In-Reply-To: <427d386f.46347@msgid.achurch.org>
References: <427d386f.46347@msgid.achurch.org>
Message-ID: <427D3AAE.3070608@winbot.co.uk>

IRC is changing. It has been changing since day one, the software which 
is used for IRC must change with it. IRCServices is being left behind by 
other software which *does* tolerate changes to the spec, and it saddens 
me to see software i love becoming deprecated because of it :-(

I'm sure there are many IRCu users out there who would disagree with 
your opinion, and as it stands ircservices simply cannot support them, 
even though it is one of the most popular IRCds. I'd say this ircd has 
more problems than mine as mine is tolerant to 'assumptions' and will 
rewrite the RFC commands to something it understands -- IRCu (P10) will 
not ;-)

Brain

Andrew Church wrote:
>>IRCServices 5 has protocol modules which allow it to connect to many 
>>different kinds of ircds easily. Great idea. However, the core blatantly 
>>uses send_cmd, and makes assumptions about the format of specific 
>>commands,
> 
> 
>      This is by design.  The only reason for protocol modules in the first
> place is to kludge around variations in what ought to be a standard.  If
> you have an ircd that's so bizarre it can't even understand a NOTICE
> message, then Services won't support it.  Sorry, but I don't have the time
> or interest to deal with such software.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> 

-- 
WinBot IRC client developer: http://www.winbot.co.uk
ChatSpike - The users network: http://www.chatspike.net
InspIRCd - Modular IRC server: http://www.inspircd.org
Online RPG Developer: http://www.ssod.org
--
From achurch at achurch.org  Sun May  8 09:09:06 2005
From: achurch at achurch.org (Andrew Church)
Date: Sat May  7 17:15:43 2005
Subject: [IRCServices Coding] send_cmd in non-protocol modules
In-Reply-To: <427D3AAE.3070608@winbot.co.uk>
Message-ID: <427d5a28.46411@msgid.achurch.org>

     I'm a bit too tired right now to go into exhaustive detail, but the
basic issue is that Services is designed (and has been designed from the
start) around a core feature set, which includes, among other things, the
NOTICE message.  Redesigning Services to eliminate those assumptions is a
_lot_ of work--it's the kind of thing that belongs in an x.0 development
cycle.  And as I've probably mentioned from time to time, I don't like
adding quick and dirty hacks to support new features; that way lies
madness.  If I still have any energy left for Services after finishing up
version 5.1, ask me then, but for the time being Services will remain
IRC2-based.

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

>IRC is changing. It has been changing since day one, the software which 
>is used for IRC must change with it. IRCServices is being left behind by 
>other software which *does* tolerate changes to the spec, and it saddens 
>me to see software i love becoming deprecated because of it :-(
>
>I'm sure there are many IRCu users out there who would disagree with 
>your opinion, and as it stands ircservices simply cannot support them, 
>even though it is one of the most popular IRCds. I'd say this ircd has 
>more problems than mine as mine is tolerant to 'assumptions' and will 
>rewrite the RFC commands to something it understands -- IRCu (P10) will 
>not ;-)
>
>Brain
>
>Andrew Church wrote:
>>>IRCServices 5 has protocol modules which allow it to connect to many 
>>>different kinds of ircds easily. Great idea. However, the core blatantly 
>>>uses send_cmd, and makes assumptions about the format of specific 
>>>commands,
>> 
>> 
>>      This is by design.  The only reason for protocol modules in the first
>> place is to kludge around variations in what ought to be a standard.  If
>> you have an ircd that's so bizarre it can't even understand a NOTICE
>> message, then Services won't support it.  Sorry, but I don't have the time
>> or interest to deal with such software.
>> 
>>   --Andrew Church
>>     achurch@achurch.org
>>     http://achurch.org/
>> ------------------------------------------------------------------
>> To unsubscribe or change your subscription options, visit:
>> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>> 
>> 
>
>-- 
>WinBot IRC client developer: http://www.winbot.co.uk
>ChatSpike - The users network: http://www.chatspike.net
>InspIRCd - Modular IRC server: http://www.inspircd.org
>Online RPG Developer: http://www.ssod.org
>--
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From ballsy at mystical.net  Mon May  9 10:58:25 2005
From: ballsy at mystical.net (David)
Date: Mon May  9 20:08:41 2005
Subject: [IRCServices Coding] send_cmd in non-protocol modules
In-Reply-To: <427D3AAE.3070608@winbot.co.uk>
References: <427d386f.46347@msgid.achurch.org> <427D3AAE.3070608@winbot.co.uk>
Message-ID: <200505091158250255.C8AD859E@smtp.messaging.ca.mci.com>

        Would it not therefore seem more logical to update or create new RFCs pertaining to IRC, instead of having to customize Services each time another non-RFC-compliant IRCd implements a 'desireable' feature?  I'm no software developer, but if I were, I wouldn't consider it unreasonable to set out some guidelines within whose confines I'd prefer to remain.
        That being said, if IRCServices continues to implement a number of ad-hoc modifications which don't follow an RFC, what happens if/when a new RFC *is* written which serves to address the aforementioned ad-hoc changes?  More work for the developers, from what I can tell, to ensure their previously implemented workarounds meet the newly released standards.

David


On 07/05/2005 at 11:01 PM Craig Edwards wrote:

>IRC is changing. It has been changing since day one, the software which 
>is used for IRC must change with it. IRCServices is being left behind by 
>other software which *does* tolerate changes to the spec, and it saddens 
>me to see software i love becoming deprecated because of it :-(
>
>I'm sure there are many IRCu users out there who would disagree with 
>your opinion, and as it stands ircservices simply cannot support them, 
>even though it is one of the most popular IRCds. I'd say this ircd has 
>more problems than mine as mine is tolerant to 'assumptions' and will 
>rewrite the RFC commands to something it understands -- IRCu (P10) will 
>not ;-)
>
>Brain
>
>Andrew Church wrote:
>>>IRCServices 5 has protocol modules which allow it to connect to many 
>>>different kinds of ircds easily. Great idea. However, the core blatantly 
>>>uses send_cmd, and makes assumptions about the format of specific 
>>>commands,
>> 
>> 
>>      This is by design.  The only reason for protocol modules in the
>first
>> place is to kludge around variations in what ought to be a standard.  If
>> you have an ircd that's so bizarre it can't even understand a NOTICE
>> message, then Services won't support it.  Sorry, but I don't have the
>time
>> or interest to deal with such software.
>> 
>>   --Andrew Church
>>     achurch@achurch.org
>>     http://achurch.org/
>> ------------------------------------------------------------------
>> To unsubscribe or change your subscription options, visit:
>> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>> 
>> 
>
>-- 
>WinBot IRC client developer: http://www.winbot.co.uk
>ChatSpike - The users network: http://www.chatspike.net
>InspIRCd - Modular IRC server: http://www.inspircd.org
>Online RPG Developer: http://www.ssod.org
>--
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding



From achurch at achurch.org  Tue May 10 12:52:47 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon May  9 20:57:21 2005
Subject: [IRCServices Coding] send_cmd in non-protocol modules
In-Reply-To: <200505091158250255.C8AD859E@smtp.messaging.ca.mci.com>
Message-ID: <42803119.47206@msgid.achurch.org>

     That would certainly be preferable, but so far nobody seems to have
done that (nor do the ircd developers seem very interested in working
together on creating such a document).

     Actually, that's not quite accurate, since RFCs 2810-2813 were
published at one point, but nobody seems to be paying attention to them...

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

>       Would it not therefore seem more logical to update or create new RFCs pertaining to IRC, instead of having to customize Services each time another non-RFC-compliant IRCd implements a 'desireable' feature?  I'm no software developer, but if I were, I wouldn't consider it unreasonable to set out some guidelines within whose confines I'd prefer to remain.
>       That being said, if IRCServices continues to implement a number of ad-hoc modifications which don't follow an RFC, what happens if/when a new RFC *is* written which serves to address the aforementioned ad-hoc changes?  More work for the developers, from what I can tell, to ensure their previously implemented workarounds meet the newly released standards.
>
>David
>
>
>On 07/05/2005 at 11:01 PM Craig Edwards wrote:
>
>>IRC is changing. It has been changing since day one, the software which 
>>is used for IRC must change with it. IRCServices is being left behind by 
>>other software which *does* tolerate changes to the spec, and it saddens 
>>me to see software i love becoming deprecated because of it :-(
>>
>>I'm sure there are many IRCu users out there who would disagree with 
>>your opinion, and as it stands ircservices simply cannot support them, 
>>even though it is one of the most popular IRCds. I'd say this ircd has 
>>more problems than mine as mine is tolerant to 'assumptions' and will 
>>rewrite the RFC commands to something it understands -- IRCu (P10) will 
>>not ;-)
>>
>>Brain
>>
>>Andrew Church wrote:
>>>>IRCServices 5 has protocol modules which allow it to connect to many 
>>>>different kinds of ircds easily. Great idea. However, the core blatantly 
>>>>uses send_cmd, and makes assumptions about the format of specific 
>>>>commands,
>>> 
>>> 
>>>      This is by design.  The only reason for protocol modules in the
>>first
>>> place is to kludge around variations in what ought to be a standard.  If
>>> you have an ircd that's so bizarre it can't even understand a NOTICE
>>> message, then Services won't support it.  Sorry, but I don't have the
>>time
>>> or interest to deal with such software.
>>> 
>>>   --Andrew Church
>>>     achurch@achurch.org
>>>     http://achurch.org/
>>> ------------------------------------------------------------------
>>> To unsubscribe or change your subscription options, visit:
>>> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>>> 
>>> 
>>
>>-- 
>>WinBot IRC client developer: http://www.winbot.co.uk
>>ChatSpike - The users network: http://www.chatspike.net
>>InspIRCd - Modular IRC server: http://www.inspircd.org
>>Online RPG Developer: http://www.ssod.org
>>--
>>------------------------------------------------------------------
>>To unsubscribe or change your subscription options, visit:
>>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From brain at winbot.co.uk  Tue May 10 05:03:35 2005
From: brain at winbot.co.uk (Craig Edwards)
Date: Tue May 10 05:03:27 2005
Subject: [IRCServices Coding] send_cmd in non-protocol modules
In-Reply-To: <42803119.47206@msgid.achurch.org>
References: <42803119.47206@msgid.achurch.org>
Message-ID: <4280A317.5030405@winbot.co.uk>

nobody pays any attention to them because a lot of it was unfortunately 
IRCNet specific. What makes it worse is that now IRCNet is throwing 
their own specs in the bin (without writing new ones i might add to take 
their place) -- for example did you know the pipe character ("|") is now 
ILLEGAL in nicknames on ircnet? - it's a new feature of their ircd2.x 
line. They took it *out* of the BNF for allowed nicknames, i'm not just 
referring to a Q line! Not just this but there have been many other 
changes 'in the name of compatibility'. Compatibility? pffft.

Brain

Andrew Church wrote:
>      That would certainly be preferable, but so far nobody seems to have
> done that (nor do the ircd developers seem very interested in working
> together on creating such a document).
> 
>      Actually, that's not quite accurate, since RFCs 2810-2813 were
> published at one point, but nobody seems to be paying attention to them...
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> 
> 
>>      Would it not therefore seem more logical to update or create new RFCs pertaining to IRC, instead of having to customize Services each time another non-RFC-compliant IRCd implements a 'desireable' feature?  I'm no software developer, but if I were, I wouldn't consider it unreasonable to set out some guidelines within whose confines I'd prefer to remain.
>>      That being said, if IRCServices continues to implement a number of ad-hoc modifications which don't follow an RFC, what happens if/when a new RFC *is* written which serves to address the aforementioned ad-hoc changes?  More work for the developers, from what I can tell, to ensure their previously implemented workarounds meet the newly released standards.
>>
>>David
>>
>>
>>On 07/05/2005 at 11:01 PM Craig Edwards wrote:
>>
>>
>>>IRC is changing. It has been changing since day one, the software which 
>>>is used for IRC must change with it. IRCServices is being left behind by 
>>>other software which *does* tolerate changes to the spec, and it saddens 
>>>me to see software i love becoming deprecated because of it :-(
>>>
>>>I'm sure there are many IRCu users out there who would disagree with 
>>>your opinion, and as it stands ircservices simply cannot support them, 
>>>even though it is one of the most popular IRCds. I'd say this ircd has 
>>>more problems than mine as mine is tolerant to 'assumptions' and will 
>>>rewrite the RFC commands to something it understands -- IRCu (P10) will 
>>>not ;-)
>>>
>>>Brain
>>>
>>>Andrew Church wrote:
>>>
>>>>>IRCServices 5 has protocol modules which allow it to connect to many 
>>>>>different kinds of ircds easily. Great idea. However, the core blatantly 
>>>>>uses send_cmd, and makes assumptions about the format of specific 
>>>>>commands,
>>>>
>>>>
>>>>     This is by design.  The only reason for protocol modules in the
>>>
>>>first
>>>
>>>>place is to kludge around variations in what ought to be a standard.  If
>>>>you have an ircd that's so bizarre it can't even understand a NOTICE
>>>>message, then Services won't support it.  Sorry, but I don't have the
>>>
>>>time
>>>
>>>>or interest to deal with such software.
>>>>
>>>>  --Andrew Church
>>>>    achurch@achurch.org
>>>>    http://achurch.org/
>>>>------------------------------------------------------------------
>>>>To unsubscribe or change your subscription options, visit:
>>>>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>>>>
>>>>
>>>
>>>-- 
>>>WinBot IRC client developer: http://www.winbot.co.uk
>>>ChatSpike - The users network: http://www.chatspike.net
>>>InspIRCd - Modular IRC server: http://www.inspircd.org
>>>Online RPG Developer: http://www.ssod.org
>>>--
>>>------------------------------------------------------------------
>>>To unsubscribe or change your subscription options, visit:
>>>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>>
>>
>>
>>------------------------------------------------------------------
>>To unsubscribe or change your subscription options, visit:
>>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> 

-- 
WinBot IRC client developer: http://www.winbot.co.uk
ChatSpike - The users network: http://www.chatspike.net
InspIRCd - Modular IRC server: http://www.inspircd.org
Online RPG Developer: http://www.ssod.org
--
From phan70m at gmail.com  Sun May 15 08:11:03 2005
From: phan70m at gmail.com (Anton Wolkov)
Date: Sun May 15 08:11:12 2005
Subject: [IRCServices Coding] a little feature suggestion
Message-ID: <d50f59a0050515081138fd6699@mail.gmail.com>

hi,
it would be nice to have chanserv op, halfop, voice commands would
accept multiple nicknames.
shouldn't be too hard, just a small loop, and it would be useful i think.
thanks
From toxyc at ircpage.com  Sun Jul  3 07:47:10 2005
From: toxyc at ircpage.com (Toxyc)
Date: Sun Jul  3 11:00:59 2005
Subject: [IRCServices Coding] module programming questions
Message-ID: <42C7FA6E.7080005@ircpage.com>

hi all

I have started module programming for about a week ago, although i have
been using ircservices for years. I have already read the manual, but i
can't find some answers in it.
My questions are:

1. I saw in the memoserv module an array (static Command cmds[]), which
(i think) used to declare the commands, which  users can use on irc. I
searched for the definition of Command structure, and found it in
commands.h but can't understand what the variables does. Can anybody
explain me what (*has_priv)(User *u), helpmsg_all, etc does to the
module? Or can i write a fully functional modul without using functions
and structures in command.c or .h?

2. When I compile a module, which provides a new pseudoclient, will it
be available after rehashing, or i need to restart services?

3. Is there any list with some description about available functions
like get_user, is_oper, send_cmd, etc etc... I know the definitions are
in extern.h and i can find the functions in the .c files, but there
aren't and description what the functions actually does. If there aren't
any documentation i will try to find it out from the source, i know,
it's an alternative, but it would be better to have docs :)

thanks in advance
Toxyc

From surreal.w00t at gmail.com  Sun Jul  3 16:01:16 2005
From: surreal.w00t at gmail.com (w00t)
Date: Sun Jul  3 16:01:29 2005
Subject: [IRCServices Coding] module programming questions
In-Reply-To: <42C7FA6E.7080005@ircpage.com>
Message-ID: <DNEGIFBFOLDCIFPEHKPJAEGHCAAA.surreal.w00t@gmail.com>

G'day,

Can't really help you with the first problem - been way too long since
I've looked at the ircservices client modules.

As for the second, it *should* be available on rehash, but I believe some
odd behaviour has been seen by some people and a rehash is recommended.

As for 3, no, to my knowledge there isn't - yes, it would be useful as it
would save duplication work.

Ta,
w00t

-----Original Message-----
From: ircservices-coding-bounces@ircservices.esper.net
[mailto:ircservices-coding-bounces@ircservices.esper.net]On Behalf Of Toxyc
Sent: Monday, 4 July 2005 12:47 AM
To: ircservices-coding@ircservices.esper.net
Subject: [IRCServices Coding] module programming questions

From toxyc at ircpage.com  Mon Jul  4 03:16:03 2005
From: toxyc at ircpage.com (Toxyc)
Date: Mon Jul  4 03:16:15 2005
Subject: [IRCServices Coding] module programming questions
In-Reply-To: <DNEGIFBFOLDCIFPEHKPJAEGHCAAA.surreal.w00t@gmail.com>
References: <DNEGIFBFOLDCIFPEHKPJAEGHCAAA.surreal.w00t@gmail.com>
Message-ID: <42C90C63.4080402@ircpage.com>

first of all, thanks for your reply, though one of my problems is still 
unsolved (the first one).
As for the second, it really loads the module on a rehash. It wasn't in 
the 6. section of the docs, which i read recently, but in /msg operserv 
help rehash, which i never read as i thought i knew what rehash does... 
I wonder why i didn't notice this earlier :(

thanks anyway
Toxyc

w00t wrote:

>G'day,
>
>Can't really help you with the first problem - been way too long since
>I've looked at the ircservices client modules.
>
>As for the second, it *should* be available on rehash, but I believe some
>odd behaviour has been seen by some people and a rehash is recommended.
>
>As for 3, no, to my knowledge there isn't - yes, it would be useful as it
>would save duplication work.
>
>Ta,
>w00t
>
From Craig at frostycoolslug.com  Wed Jul 13 13:37:18 2005
From: Craig at frostycoolslug.com (Craig McLure)
Date: Wed Jul 13 13:37:29 2005
Subject: [IRCServices Coding] cb_unset
Message-ID: <42D57B7E.2020009@frostycoolslug.com>

Whilst browsing through the source, i've noticed a callback added for 
the nickserv SET command, however, i feel it would probably be 
appropriate to add one for UNSET as well, I don't want to modify the 
core services files, so i'm asking if there is an 'official' way to 
either hook the unset command, or if one plans to be added in the future.

Thanks

-- 
/****************************************
  *     Craig "FrostyCoolSlug" McLure
  *       Craig@FrostyCoolSlug.com
  * InspIRCd   - http://www.inspircd.org
  * ChatSpike  - http://www.chatspike.net
  ****************************************/

From phan70m at gmail.com  Wed Jul 20 06:26:09 2005
From: phan70m at gmail.com (Anton Wolkov)
Date: Wed Jul 20 06:28:33 2005
Subject: [IRCServices Coding] cb_unset
In-Reply-To: <42D57B7E.2020009@frostycoolslug.com>
References: <42D57B7E.2020009@frostycoolslug.com>
Message-ID: <d50f59a005072006265dd1671@mail.gmail.com>

Yep, i actually added this one myself for my vhost module that uses set and 
unset of nickserv.
Would be usefull to have in the official version.

 On 7/13/05, Craig McLure <Craig@frostycoolslug.com> wrote: 
> 
> Whilst browsing through the source, i've noticed a callback added for
> the nickserv SET command, however, i feel it would probably be
> appropriate to add one for UNSET as well, I don't want to modify the
> core services files, so i'm asking if there is an 'official' way to
> either hook the unset command, or if one plans to be added in the future.
> 
> Thanks
> 
> --
> /****************************************
> * Craig "FrostyCoolSlug" McLure
> * Craig@FrostyCoolSlug.com
> * InspIRCd - http://www.inspircd.org
> * ChatSpike - http://www.chatspike.net
> ****************************************/
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20050720/c6e580a3/attachment.html
From achurch at achurch.org  Sat Aug 13 12:04:32 2005
From: achurch at achurch.org (Andrew Church)
Date: Sat Aug 13 18:58:13 2005
Subject: [IRCServices Coding] module programming questions
In-Reply-To: <42C7FA6E.7080005@ircpage.com>
Message-ID: <42fea528.74221@msgid.achurch.org>

     Apologies for the delay in replying; I've been busy lately.

>1. I saw in the memoserv module an array (static Command cmds[]), which
>(i think) used to declare the commands, which  users can use on irc. I
>searched for the definition of Command structure, and found it in
>commands.h but can't understand what the variables does. Can anybody
>explain me what (*has_priv)(User *u), helpmsg_all, etc does to the
>module? Or can i write a fully functional modul without using functions
>and structures in command.c or .h?

     The commands.[ch] files are intended to help with processing
pseudoclient commands, by letting you provide a list of commands available
which can then be searched by the functions in commands.c.  It's not
necessary, however.

>2. When I compile a module, which provides a new pseudoclient, will it
>be available after rehashing, or i need to restart services?

     The module itself will be loaded after a REHASH (I've clarified this
in the documentation), so as long as your init_module() function introduces
the nickname, it'll be available.

>3. Is there any list with some description about available functions
>like get_user, is_oper, send_cmd, etc etc... I know the definitions are
>in extern.h and i can find the functions in the .c files, but there
>aren't and description what the functions actually does. If there aren't
>any documentation i will try to find it out from the source, i know,
>it's an alternative, but it would be better to have docs :)

     A design document detailing all of this information is something I'm
hoping to have done for version 5.1.  (I'd actually hoped to have it for
5.0, but you can see how well that plan worked out...)

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Sat Aug 13 12:19:35 2005
From: achurch at achurch.org (Andrew Church)
Date: Sat Aug 13 18:58:33 2005
Subject: [IRCServices Coding] cb_unset
In-Reply-To: <42D57B7E.2020009@frostycoolslug.com>
Message-ID: <42fea53e.74233@msgid.achurch.org>

>Whilst browsing through the source, i've noticed a callback added for 
>the nickserv SET command, however, i feel it would probably be 
>appropriate to add one for UNSET as well, I don't want to modify the 
>core services files, so i'm asking if there is an 'official' way to 
>either hook the unset command, or if one plans to be added in the future.

     I've added an UNSET callback for NickServ and ChanServ for 5.0.54.
The calling format is the same as for the SET callback, except that the
last parameter ("param") is omitted.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From olly at avansys.co.uk  Mon Aug 15 04:09:08 2005
From: olly at avansys.co.uk (Olly)
Date: Mon Aug 15 04:09:00 2005
Subject: [IRCServices Coding] Introduced module's Psuedoclient is invalid
        user.
Message-ID: <22d5e19ab79e104e913cd28c8ac30583@avansys.co.uk>

Hi
I seem to have screwed up somewhere, but can't see where.
I have stolen module code, from a module coded by ChatSpike.net (Thanks
Brain and the crew) and have modified it a little.
The problem is when I try to discover what the psuedoclient's channel
status is. All I get in the debug logs is a request has been made for an
"invalid user". If I attempt to discover any info using any of the
call-backs, I either get a seg fault or no reply. I imagine this is due
to the pseudoclient's Nick not having any valid user. The kind of info I
am after is whether the Psuedoclient is opped in any particular channel,
or if it has been kicked. None of the call-backs will give me any of
this info, and direct use of the standard APIs like:

is_chanop(User *user, const char *chan) 

causes a crash because get_user(PsuedoclientNick) returns NULL I expect.

I even attempted to add a custom is_chanop routine to the module which
searched using just the nick but then

    LIST_SEARCH(c->users, user->nick, user->nick, irc_stricmp, cu);

gave me a problem because it too requires a valid user to work with, and
all I can seem to provide is just a nick.

do_intoduce appears to work correctly yet CS still alters the channel
status of the module's pseudoclient despite it's being a Services User.

Here's the beginning code for do_introduce which is taken directly from
Chatspike's module.

static int do_introduce(const char *nick)
{
        ChannelInfo *ci;static int do_introduce(const char *nick)
        char chan[1024];
        FILE* f;
        if (!nick || irc_stricmp(nick, s_ModuleNick) == 0) {
                send_nick(s_IdleServ, ServiceUser, ServiceHost,
ServerName,
                desc_IdleServ, pseudoclient_modes);
                if (nick)
                    return 1;

Any ideas/help appreciated.

Thanks.

Olly

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Winmail.dat
Type: application/ms-tnef
Size: 5203 bytes
Desc: not available
Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20050815/d6f8ffa0/Winmail-0001.bin
From surreal.w00t at gmail.com  Mon Aug 15 04:28:48 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Mon Aug 15 04:29:21 2005
Subject: [IRCServices Coding] Introduced module's Psuedoclient is invalid
        user.
In-Reply-To: <22d5e19ab79e104e913cd28c8ac30583@avansys.co.uk>
References: <22d5e19ab79e104e913cd28c8ac30583@avansys.co.uk>
Message-ID: <43007C70.7060500@gmail.com>

Aha - let me guess, you're working on a botserv? ;)

Alas, it's not that simple, Services doesn't know about users on their 
own server (chanserv, nickserv and any other pseudoclients). So really, 
there isn't a way to accomplish this, at least, not easily that we've 
been able to think of yet. (myself craig, and brain did some 
brainstorming on this a while back (last year?), can't remember what we 
ended up thinking.

Olly wrote:
> Hi
> I seem to have screwed up somewhere, but can't see where.
> I have stolen module code, from a module coded by ChatSpike.net (Thanks
> Brain and the crew) and have modified it a little.
> The problem is when I try to discover what the psuedoclient's channel
> status is. All I get in the debug logs is a request has been made for an
> "invalid user". If I attempt to discover any info using any of the
> call-backs, I either get a seg fault or no reply. I imagine this is due
> to the pseudoclient's Nick not having any valid user. The kind of info I
> am after is whether the Psuedoclient is opped in any particular channel,
> or if it has been kicked. None of the call-backs will give me any of
> this info, and direct use of the standard APIs like:
> 
> is_chanop(User *user, const char *chan) 
> 
> causes a crash because get_user(PsuedoclientNick) returns NULL I expect.
> 
> I even attempted to add a custom is_chanop routine to the module which
> searched using just the nick but then
> 
>     LIST_SEARCH(c->users, user->nick, user->nick, irc_stricmp, cu);
> 
> gave me a problem because it too requires a valid user to work with, and
> all I can seem to provide is just a nick.
> 
> do_intoduce appears to work correctly yet CS still alters the channel
> status of the module's pseudoclient despite it's being a Services User.
> 
> Here's the beginning code for do_introduce which is taken directly from
> Chatspike's module.
> 
> static int do_introduce(const char *nick)
> {
>         ChannelInfo *ci;static int do_introduce(const char *nick)
>         char chan[1024];
>         FILE* f;
>         if (!nick || irc_stricmp(nick, s_ModuleNick) == 0) {
>                 send_nick(s_IdleServ, ServiceUser, ServiceHost,
> ServerName,
>                 desc_IdleServ, pseudoclient_modes);
>                 if (nick)
>                     return 1;
> 
> Any ideas/help appreciated.
> 
> Thanks.
> 
> Olly
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding

From olly at avansys.co.uk  Mon Aug 15 05:37:44 2005
From: olly at avansys.co.uk (Olly)
Date: Mon Aug 15 05:37:30 2005
Subject: [IRCServices Coding] Introduced module's Psuedoclient is invalid
        user.
In-Reply-To: <43007C70.7060500@gmail.com>
Message-ID: <bd24906b67cabf40bfc73f4d7546a6c5@avansys.co.uk>

Hehe how did you know?

Okay here's a couple of questions..
Can I force Services to produce a valid user struct for the
psuedoclient?
Can I find out if a channel join from any user is the first time that an
empty channel has been joined?

The first would solve all my problems methinks, but failing that then
the second would be a satisfactory workaround as it's the only time the
de-op problem arises.

I can live without the kick thing as only Opers and Services can kick
the client anyway.

Olly

-----Original Message-----
From: ircservices-coding-bounces@ircservices.esper.net
[mailto:ircservices-coding-bounces@ircservices.esper.net]On Behalf Of
Robin Burchell
Sent: 15 August 2005 12:29
To: IRC Services Coding Mailing List
Subject: Re: [IRCServices Coding] Introduced module's Psuedoclient is
invalid user.


Aha - let me guess, you're working on a botserv? ;)

Alas, it's not that simple, Services doesn't know about users on their 
own server (chanserv, nickserv and any other pseudoclients). So really, 
there isn't a way to accomplish this, at least, not easily that we've 
been able to think of yet. (myself craig, and brain did some 
brainstorming on this a while back (last year?), can't remember what we 
ended up thinking.




From achurch at achurch.org  Mon Aug 15 21:36:33 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 15 05:38:26 2005
Subject: [IRCServices Coding] Introduced module's Psuedoclient is invalid
        user.
In-Reply-To: <43007C70.7060500@gmail.com>
Message-ID: <43008cb9.75052@msgid.achurch.org>

     What you need to do in this case is keep track of the pseudoclients'
status yourself, like how the autokick code keeps track of which channels
ChanServ is in.  The User structure is for users monitored by Services, not
for pseudoclients.

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

>Aha - let me guess, you're working on a botserv? ;)
>
>Alas, it's not that simple, Services doesn't know about users on their 
>own server (chanserv, nickserv and any other pseudoclients). So really, 
>there isn't a way to accomplish this, at least, not easily that we've 
>been able to think of yet. (myself craig, and brain did some 
>brainstorming on this a while back (last year?), can't remember what we 
>ended up thinking.
>
>Olly wrote:
>> Hi
>> I seem to have screwed up somewhere, but can't see where.
>> I have stolen module code, from a module coded by ChatSpike.net (Thanks
>> Brain and the crew) and have modified it a little.
>> The problem is when I try to discover what the psuedoclient's channel
>> status is. All I get in the debug logs is a request has been made for an
>> "invalid user". If I attempt to discover any info using any of the
>> call-backs, I either get a seg fault or no reply. I imagine this is due
>> to the pseudoclient's Nick not having any valid user. The kind of info I
>> am after is whether the Psuedoclient is opped in any particular channel,
>> or if it has been kicked. None of the call-backs will give me any of
>> this info, and direct use of the standard APIs like:
>> 
>> is_chanop(User *user, const char *chan) 
>> 
>> causes a crash because get_user(PsuedoclientNick) returns NULL I expect.
>> 
>> I even attempted to add a custom is_chanop routine to the module which
>> searched using just the nick but then
>> 
>>     LIST_SEARCH(c->users, user->nick, user->nick, irc_stricmp, cu);
>> 
>> gave me a problem because it too requires a valid user to work with, and
>> all I can seem to provide is just a nick.
>> 
>> do_intoduce appears to work correctly yet CS still alters the channel
>> status of the module's pseudoclient despite it's being a Services User.
>> 
>> Here's the beginning code for do_introduce which is taken directly from
>> Chatspike's module.
>> 
>> static int do_introduce(const char *nick)
>> {
>>         ChannelInfo *ci;static int do_introduce(const char *nick)
>>         char chan[1024];
>>         FILE* f;
>>         if (!nick || irc_stricmp(nick, s_ModuleNick) == 0) {
>>                 send_nick(s_IdleServ, ServiceUser, ServiceHost,
>> ServerName,
>>                 desc_IdleServ, pseudoclient_modes);
>>                 if (nick)
>>                     return 1;
>> 
>> Any ideas/help appreciated.
>> 
>> Thanks.
>> 
>> Olly
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> ------------------------------------------------------------------
>> To unsubscribe or change your subscription options, visit:
>> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
From achurch at achurch.org  Mon Aug 15 21:38:33 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 15 05:40:44 2005
Subject: [IRCServices Coding] Introduced module's Psuedoclient is invalid
        user.
In-Reply-To: <bd24906b67cabf40bfc73f4d7546a6c5@avansys.co.uk>
Message-ID: <43008d47.75063@msgid.achurch.org>

     Looks like our messages crossed paths, but--

>Okay here's a couple of questions..
>Can I force Services to produce a valid user struct for the
>psuedoclient?

     No, as per my previous mail.

>Can I find out if a channel join from any user is the first time that an
>empty channel has been joined?

     See the autokick code in modules/chanserv/check.c:check_kick(), which
includes code (and comments) to check whether a user is the only user in
the channel both at and after join time.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From olly at avansys.co.uk  Mon Aug 15 10:06:23 2005
From: olly at avansys.co.uk (Olly)
Date: Mon Aug 15 10:06:17 2005
Subject: [IRCServices Coding] Introduced module's Psuedoclient is invalid
        user.
In-Reply-To: <43008d47.75063@msgid.achurch.org>
Message-ID: <04629d8af4b4ed438fc9b2517103a456@avansys.co.uk>

This is crazy. For some reason I can't seem to get a valid channelinfo
struct from the check_kick call-back, so I can't tell which channel is
being joined. Is this a bug, or am I missing something?

Olly

-----Original Message-----
From: ircservices-coding-bounces@ircservices.esper.net
[mailto:ircservices-coding-bounces@ircservices.esper.net]On Behalf Of
Andrew Church
Sent: 15 August 2005 22:39
To: ircservices-coding@ircservices.esper.net
Subject: RE: [IRCServices Coding] Introduced module's Psuedoclient is
invalid user.


     Looks like our messages crossed paths, but--

>Okay here's a couple of questions..
>Can I force Services to produce a valid user struct for the
>psuedoclient?

     No, as per my previous mail.

>Can I find out if a channel join from any user is the first time that
an
>empty channel has been joined?

     See the autokick code in modules/chanserv/check.c:check_kick(),
which
includes code (and comments) to check whether a user is the only user in
the channel both at and after join time.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
------------------------------------------------------------------
To unsubscribe or change your subscription options, visit:
http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding



From achurch at achurch.org  Tue Aug 16 11:04:47 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 15 19:07:35 2005
Subject: [IRCServices Coding] Introduced module's Psuedoclient is invalid
        user.
In-Reply-To: <04629d8af4b4ed438fc9b2517103a456@avansys.co.uk>
Message-ID: <43014a5b.75205@msgid.achurch.org>

>This is crazy. For some reason I can't seem to get a valid channelinfo
>struct from the check_kick call-back, so I can't tell which channel is
>being joined. Is this a bug, or am I missing something?

     You're missing something.  6-2-4, check_kick: "Called when checking
whether a user should be kicked from a channel, before any standard checks
are performed.  user will not be NULL, but either or both of c and ci may
be NULL if the channel is currently empty or not registered, respectively."

     On second thought, if the channel's empty that leaves you with no way
to figure out what channel it is.  Good point, I'll fix it.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From phan70m at gmail.com  Mon Aug 22 03:25:41 2005
From: phan70m at gmail.com (Anton Wolkov)
Date: Mon Aug 22 03:26:05 2005
Subject: [IRCServices Coding] channel modes bug report
Message-ID: <d50f59a005082203254ed22715@mail.gmail.com>

Hi,
just noticed something weird, services try to do ircd's job by not letting 
users without channel op to add modes like half-ops and voices, problem is 
this is done really poorly on unrealircd which does this on his own fairly 
good.
here's an example:

> *** SoCkX (~a@NiX-B9069B23.iplei.pt <http://NiX-B9069B23.iplei.pt>) has 
> joined #somechan
> * ChanServ sets mode: +o SoCkX
> * SoCkX sets mode: -o+hv SoCkX SoCkX SoCkX
> * ChanServ sets mode: -h SoCkX

See how the voice is unset? and how this user should have +h?
This however will not happen if

> *** SoCkX (~a@NiX-B9069B23.iplei.pt <http://NiX-B9069B23.iplei.pt>) has 
> joined #somechan
> * ChanServ sets mode: +o SoCkX
> * SoCkX sets mode: +hv-o SoCkX SoCkX SoCkX
> 
This is exactly the same for the ircd, but it's not for the services.
Even if this is desired functionality, it's done poorly since only the first 
mode is actually unset, though i believe it isn't.
Hope this helps,

Best Regards,
PHANTOm < phantom@nix.co.il > -- www.irc.nix.co.il<http://www.irc.nix.co.il/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20050822/5ddb9d11/attachment.html
From surreal.w00t at gmail.com  Mon Aug 22 03:32:35 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Mon Aug 22 03:33:09 2005
Subject: [IRCServices Coding] channel modes bug report
In-Reply-To: <d50f59a005082203254ed22715@mail.gmail.com>
References: <d50f59a005082203254ed22715@mail.gmail.com>
Message-ID: <4309A9C3.9060709@gmail.com>

Basically because ChanServ sees the -o, processes that, then sees that 
you don't have permissions to perform +h.

That'd be my guess anyhow, I'm not too familar with the core of 
ircservices yet.

Anton Wolkov wrote:
> Hi,
> just noticed something weird, services try to do ircd's job by not 
> letting users without channel op to add modes like half-ops and voices, 
> problem is this is done really poorly on unrealircd which does this on 
> his own fairly good.
> here's an example:
> 
>     *** SoCkX (~a@ NiX-B9069B23.iplei.pt <http://NiX-B9069B23.iplei.pt>)
>     has joined #somechan
>     * ChanServ sets mode: +o SoCkX
>     * SoCkX sets mode: -o+hv SoCkX SoCkX SoCkX
>     * ChanServ sets mode: -h SoCkX
> 
> See how the voice is unset? and how this user should have +h?
> This however will not happen if
> 
>     *** SoCkX (~a@ NiX-B9069B23.iplei.pt <http://NiX-B9069B23.iplei.pt>)
>     has joined #somechan
>     * ChanServ sets mode: +o SoCkX
>     * SoCkX sets mode: +hv-o SoCkX SoCkX SoCkX
> 
> This is exactly the same for the ircd, but it's not for the services.
> Even if this is desired functionality, it's done poorly since only the 
> first mode is actually unset, though i believe it isn't.
> Hope this helps,
> 
> Best Regards,
> PHANTOm < phantom@nix.co.il <mailto:phantom@nix.co.il> > -- 
> www.irc.nix.co.il <http://www.irc.nix.co.il/>
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding

From achurch at achurch.org  Mon Aug 22 20:33:26 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 22 04:34:05 2005
Subject: [IRCServices Coding] channel modes bug report
In-Reply-To: <d50f59a005082203254ed22715@mail.gmail.com>
Message-ID: <4309b81c.07004@msgid.achurch.org>

RTFM (FAQ E.8), and don't use HTML mail.

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

>--===============0591489499==
>Content-Type: multipart/alternative; 
>       boundary="----=_Part_6963_25044273.1124706341036"
>
>------=_Part_6963_25044273.1124706341036
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>
>Hi,
>just noticed something weird, services try to do ircd's job by not letting=
>=20
>users without channel op to add modes like half-ops and voices, problem is=
>=20
>this is done really poorly on unrealircd which does this on his own fairly=
>=20
>good.
>here's an example:
>
>> *** SoCkX (~a@NiX-B9069B23.iplei.pt <http://NiX-B9069B23.iplei.pt>) has=
>=20
>> joined #somechan
>> * ChanServ sets mode: +o SoCkX
>> * SoCkX sets mode: -o+hv SoCkX SoCkX SoCkX
>> * ChanServ sets mode: -h SoCkX
>
>See how the voice is unset? and how this user should have +h?
>This however will not happen if
>
>> *** SoCkX (~a@NiX-B9069B23.iplei.pt <http://NiX-B9069B23.iplei.pt>) has=
>=20
>> joined #somechan
>> * ChanServ sets mode: +o SoCkX
>> * SoCkX sets mode: +hv-o SoCkX SoCkX SoCkX
>>=20
>This is exactly the same for the ircd, but it's not for the services.
>Even if this is desired functionality, it's done poorly since only the firs=
>t=20
>mode is actually unset, though i believe it isn't.
>Hope this helps,
>
>Best Regards,
>PHANTOm < phantom@nix.co.il > -- www.irc.nix.co.il<http://www.irc.nix.co.il=
>/>
>
>------=_Part_6963_25044273.1124706341036
>Content-Type: text/html; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>
>Hi,<br>
>just noticed something weird, services try to do ircd's job by not
>letting users without channel op to add modes like half-ops and voices,
>problem is this is done really poorly on unrealircd which does this on
>his own fairly good.<br>
>here's an example:<br>
><blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
> 0pt 0pt 0.8ex; padding-left: 1ex; background-color: rgb(204, 204, 204);" c=
>lass=3D"gmail_quote">*** SoCkX (~a@<a href=3D"http://NiX-B9069B23.iplei.pt"=
>>
>NiX-B9069B23.iplei.pt</a>) has joined #somechan<br>
>* ChanServ sets mode: +o SoCkX<br>
>* SoCkX sets mode: -o+hv SoCkX SoCkX SoCkX<br>
>* ChanServ sets mode: -h SoCkX</blockquote>
><div>See how the voice is unset? and how this user should have +h?<br>
>This however will not happen if<br>
><blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
> 0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote"><span style=3D"ba=
>ckground-color: rgb(204, 204, 204);">*** SoCkX (~a@<a href=3D"http://NiX-B9=
>069B23.iplei.pt">
>NiX-B9069B23.iplei.pt</a>) has joined #somechan</span><br style=3D"backgrou=
>nd-color: rgb(204, 204, 204);">
>  <span style=3D"background-color: rgb(204, 204, 204);">* ChanServ sets mod=
>e: +o SoCkX</span><br style=3D"background-color: rgb(204, 204, 204);">
>  <span style=3D"background-color: rgb(204, 204, 204);">* SoCkX sets mode: =
>+hv-o SoCkX SoCkX SoCkX</span><br>
></blockquote>
>This is exactly the same for the ircd, but it's not for the services.<br>
>Even if this is desired functionality, it's done poorly since only the firs=
>t mode is actually unset, though i believe it isn't.<br>
>Hope this helps,<br>
><br>
>Best Regards,<br>
>PHANTOm &lt; <a href=3D"mailto:phantom@nix.co.il">phantom@nix.co.il</a> &gt=
>; -- <a href=3D"http://www.irc.nix.co.il/">www.irc.nix.co.il</a><br>
></div>
>
>------=_Part_6963_25044273.1124706341036--
>
>--===============0591489499==
>Content-Type: text/plain; charset="us-ascii"
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
>--===============0591489499==--
From surreal.w00t at gmail.com  Mon Aug 22 04:52:05 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Mon Aug 22 04:52:49 2005
Subject: [IRCServices Coding] Possible new callback on AUTH
Message-ID: <4309BC65.9020205@gmail.com>

Hi,

I'm working on a bit of a module to orient new users, but (with spambots 
and stuff) it's a little inconvenient to do this with the register callback.

Not wanting to fork the codebase, would it be at all possible to get a 
new callback on NS AUTH?

Ta,
w00t.

--------------
ChatSpike: www.chatspike.net
InspIRCd: www.inspircd.org
From phan70m at gmail.com  Mon Aug 22 11:53:55 2005
From: phan70m at gmail.com (Anton Wolkov)
Date: Mon Aug 22 11:54:07 2005
Subject: [IRCServices Coding] channel modes bug report
In-Reply-To: <4309b81c.07004@msgid.achurch.org>
References: <d50f59a005082203254ed22715@mail.gmail.com>
        <4309b81c.07004@msgid.achurch.org>
Message-ID: <d50f59a005082211531b8faa1c@mail.gmail.com>

Sorry about the HTML, in any case, there is a bug:

[01:11pm] *** SoCkX (~a@NiX-B9069B23.iplei.pt) has joined #CCCP
[01:11pm] * ChanServ sets mode: +o SoCkX
[01:11pm] * SoCkX sets mode: -o+hv SoCkX SoCkX SoCkX
[01:11pm] * ChanServ sets mode: -h SoCkX
the voice is not unset

[01:13pm] *** SoCkX (~a@NiX-B9069B23.iplei.pt) has joined #CCCP
[01:13pm] * ChanServ sets mode: +o SoCkX
[01:13pm] * SoCkX sets mode: -o+o SoCkX SoCkX
[01:13pm] * ChanServ sets mode: -o SoCkX
this is just plain wrong but ok

[01:15pm] *** SoCkX (~a@NiX-B9069B23.iplei.pt) has joined #CCCP
[01:15pm] * ChanServ sets mode: +o SoCkX
[01:15pm] * SoCkX sets mode: -o+v SoCkX SoCkX
[01:15pm] * ChanServ sets mode: -v SoCkX
this is designed behaviour i suppose

[01:11pm] *** SoCkX (~a@NiX-B9069B23.iplei.pt) has joined #CCCP
[01:11pm] * ChanServ sets mode: +o SoCkX
[01:11pm] * SoCkX sets mode: -o+vv SoCkX SoCkX SoCkX
[01:11pm] * ChanServ sets mode: -v SoCkX
but this sure isn't

On 8/22/05, Andrew Church <achurch@achurch.org> wrote:
> RTFM (FAQ E.8), and don't use HTML mail.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
From surreal.w00t at gmail.com  Mon Aug 22 20:59:06 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Mon Aug 22 20:59:32 2005
Subject: [IRCServices Coding] Brief question
Message-ID: <430A9F0A.10405@gmail.com>

Looking through some stuff, I've noticed this:

#ifdef CLEAN_COMPILE
         shutdown_unused = shutdown_unused;
#endif

floating around. Can someone please tell me what the heck the point of 
it is? Curiosity gets the better of me :p

[ps: sorry about all the traffic on here :) finding my way around]

Thanks,
w00t.

---------------
ChatSpike: irc.chatspike.net
InspIRCd: www.inspircd.org
From achurch at achurch.org  Tue Aug 23 13:08:22 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 22 21:12:24 2005
Subject: [IRCServices Coding] Brief question
In-Reply-To: <430A9F0A.10405@gmail.com>
Message-ID: <430aa216.12530@msgid.achurch.org>

>Looking through some stuff, I've noticed this:
>
>#ifdef CLEAN_COMPILE
>         shutdown_unused = shutdown_unused;
>#endif
>
>floating around. Can someone please tell me what the heck the point of 
>it is? Curiosity gets the better of me :p

     This is just to keep the compiler from warning about unused parameters
to functions.  (I develop with -Wall and -Werror, so those warnings,
harmless as they are, stop compilation.)  It turns out, though, that GCC4
doesn't warn about those anymore even with -Wall, so I've removed those
constructs for version 5.1.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Tue Aug 23 13:12:14 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 22 21:13:30 2005
Subject: [IRCServices Coding] Possible new callback on AUTH
In-Reply-To: <4309BC65.9020205@gmail.com>
Message-ID: <430aa265.12540@msgid.achurch.org>

>I'm working on a bit of a module to orient new users, but (with spambots 
>and stuff) it's a little inconvenient to do this with the register callback.
>
>Not wanting to fork the codebase, would it be at all possible to get a 
>new callback on NS AUTH?

     Ordinarily I'd want to wait for 5.1, but seeing as the 5.1 alpha is
already several lifetimes later than I'd hoped, why not? (:  I'll add it
for the next 5.0 release.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From achurch at achurch.org  Tue Aug 23 13:15:51 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 22 21:17:50 2005
Subject: [IRCServices Coding] channel modes bug report
In-Reply-To: <d50f59a005082211531b8faa1c@mail.gmail.com>
Message-ID: <430aa368.12557@msgid.achurch.org>

>[01:11pm] *** SoCkX (~a@NiX-B9069B23.iplei.pt) has joined #CCCP
>[01:11pm] * ChanServ sets mode: +o SoCkX
>[01:11pm] * SoCkX sets mode: -o+hv SoCkX SoCkX SoCkX
>[01:11pm] * ChanServ sets mode: -h SoCkX
>the voice is not unset

     That looks like a bug, I'll look into it.

>[01:13pm] *** SoCkX (~a@NiX-B9069B23.iplei.pt) has joined #CCCP
>[01:13pm] * ChanServ sets mode: +o SoCkX
>[01:13pm] * SoCkX sets mode: -o+o SoCkX SoCkX
>[01:13pm] * ChanServ sets mode: -o SoCkX
>this is just plain wrong but ok

     Don't do that then.  Services treats each mode change serially,
meaning that after the first -o you don't have privileges to +o yourself.
-o+o is meaningless anyway.

>[01:15pm] *** SoCkX (~a@NiX-B9069B23.iplei.pt) has joined #CCCP
>[01:15pm] * ChanServ sets mode: +o SoCkX
>[01:15pm] * SoCkX sets mode: -o+v SoCkX SoCkX
>[01:15pm] * ChanServ sets mode: -v SoCkX
>this is designed behaviour i suppose

     Yes, as above and in FAQ E.8.

>[01:11pm] *** SoCkX (~a@NiX-B9069B23.iplei.pt) has joined #CCCP
>[01:11pm] * ChanServ sets mode: +o SoCkX
>[01:11pm] * SoCkX sets mode: -o+vv SoCkX SoCkX SoCkX
>[01:11pm] * ChanServ sets mode: -v SoCkX
>but this sure isn't

     Sure it is.  +v+v is the same as a single +v, and only needs a single
-v to cancel.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Mon Aug 22 21:23:46 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Mon Aug 22 21:24:13 2005
Subject: [IRCServices Coding] Possible new callback on AUTH
In-Reply-To: <430aa265.12540@msgid.achurch.org>
References: <430aa265.12540@msgid.achurch.org>
Message-ID: <430AA4D2.70708@gmail.com>

Much appreciated. I'm using the REGISTER callback on the testnet, so
there's no rush.

Andrew Church wrote:
>>I'm working on a bit of a module to orient new users, but (with spambots 
>>and stuff) it's a little inconvenient to do this with the register callback.
>>
>>Not wanting to fork the codebase, would it be at all possible to get a 
>>new callback on NS AUTH?
> 
> 
>      Ordinarily I'd want to wait for 5.1, but seeing as the 5.1 alpha is
> already several lifetimes later than I'd hoped, why not? (:  I'll add it
> for the next 5.0 release.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 

From achurch at achurch.org  Tue Aug 23 13:24:00 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 22 21:25:03 2005
Subject: [IRCServices Coding] Possible new callback on AUTH
In-Reply-To: <430aa265.12540@msgid.achurch.org>
Message-ID: <430aa519.12601@msgid.achurch.org>

>>I'm working on a bit of a module to orient new users, but (with spambots 
>>and stuff) it's a little inconvenient to do this with the register callback.
>>
>>Not wanting to fork the codebase, would it be at all possible to get a 
>>new callback on NS AUTH?
>
>     Ordinarily I'd want to wait for 5.1, but seeing as the 5.1 alpha is
>already several lifetimes later than I'd hoped, why not? (:  I'll add it
>for the next 5.0 release.

     Actually I guess I should ask: where do you need the callback?  Is it
sufficient to have it called after all normal processing, or do you want to
replace part of the normal AUTH processing?

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Mon Aug 22 21:36:24 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Mon Aug 22 21:36:51 2005
Subject: [IRCServices Coding] Possible new callback on AUTH
In-Reply-To: <430aa519.12601@msgid.achurch.org>
References: <430aa519.12601@msgid.achurch.org>
Message-ID: <430AA7C8.2010002@gmail.com>

Andrew Church wrote:
>>>I'm working on a bit of a module to orient new users, but (with spambots 
>>>and stuff) it's a little inconvenient to do this with the register callback.
>>>
>>>Not wanting to fork the codebase, would it be at all possible to get a 
>>>new callback on NS AUTH?
>>
>>    Ordinarily I'd want to wait for 5.1, but seeing as the 5.1 alpha is
>>already several lifetimes later than I'd hoped, why not? (:  I'll add it
>>for the next 5.0 release.
> 
> 
>      Actually I guess I should ask: where do you need the callback?  Is it
> sufficient to have it called after all normal processing, or do you want to
> replace part of the normal AUTH processing?
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/

(Not sure if this sent the first time, let's try again..)

After is what I'm needing-

What I'm doing is making sure a normal user passes all checks, and if
so, sending them information - doing this on register isn't a good idea,
because of the growing number of spambots that can simply register,
putting extra load on Services.
From achurch at achurch.org  Tue Aug 23 13:40:08 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 22 21:41:24 2005
Subject: [IRCServices Coding] Possible new callback on AUTH
In-Reply-To: <430AA7C8.2010002@gmail.com>
Message-ID: <430aa8ec.12655@msgid.achurch.org>

>After is what I'm needing-
>
>What I'm doing is making sure a normal user passes all checks, and if
>so, sending them information - doing this on register isn't a good idea,
>because of the growing number of spambots that can simply register,
>putting extra load on Services.

     Okay, that's what I thought.  If you want to get started early, the
callback will be "authed", in module nickserv/mail-auth, and the parameters
are: User *u, NickInfo *ni, NickGroupInfo *ngi.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Mon Aug 22 21:52:14 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Mon Aug 22 21:52:47 2005
Subject: [IRCServices Coding] Possible new callback on AUTH
In-Reply-To: <430aa8ec.12655@msgid.achurch.org>
References: <430aa8ec.12655@msgid.achurch.org>
Message-ID: <430AAB7E.1080402@gmail.com>

Andrew Church wrote:
>>After is what I'm needing-
>>
>>What I'm doing is making sure a normal user passes all checks, and if
>>so, sending them information - doing this on register isn't a good idea,
>>because of the growing number of spambots that can simply register,
>>putting extra load on Services.
> 
> 
>      Okay, that's what I thought.  If you want to get started early, the
> callback will be "authed", in module nickserv/mail-auth, and the parameters
> are: User *u, NickInfo *ni, NickGroupInfo *ngi.
> 
>   --Andrew Church
>     achurch@achurch.org
>     http://achurch.org/

Great, much appreciated!
From achurch at achurch.org  Tue Aug 23 14:12:19 2005
From: achurch at achurch.org (Andrew Church)
Date: Mon Aug 22 22:13:18 2005
Subject: [IRCServices Coding] Possible new callback on AUTH
In-Reply-To: <430AAB7E.1080402@gmail.com>
Message-ID: <430ab067.17111@msgid.achurch.org>

>>      Okay, that's what I thought.  If you want to get started early, the
>> callback will be "authed", in module nickserv/mail-auth, and the parameters
>> are: User *u, NickInfo *ni, NickGroupInfo *ngi.
>> 
>>   --Andrew Church
>>     achurch@achurch.org
>>     http://achurch.org/
>
>Great, much appreciated!

     Actually, it just occurred to me that at the time the callback is
called, ngi->authreason will have already been cleared, so I'm adding the
old authreason as the fourth parameter (int authreason).

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From lrxlinux at verizon.net  Sat Aug 27 08:11:24 2005
From: lrxlinux at verizon.net (Randall J. Berry)
Date: Sat Aug 27 08:12:03 2005
Subject: [IRCServices Coding] ServBot Replies
Message-ID: <4310829C.9040200@verizon.net>

    Hi All,
First.. Yes I've read the FA*Q
*

<--Begin Paste
C.7. How can I make Services send replies using PRIVMSG (/msg) instead 
of NOTICE?
You can't. RFC 1459 (the IRC protocol definition) requires that all 
automated clients send all replies using NOTICE rather than PRIVMSG, and 
Services follows that requirement. If you want to change how Services 
replies appear in your IRC client, change your client's settings.
End Paste-->

I'd like to know how I can change the code to make ***Serv to reply in 
PRIVMSG/NOTICE as per user request. I understand the reason for making 
the default per RFC standard but I've seen some services that still use 
MSG and some that allow the user to choose how they want the bot to 
reply. Beyond IRC services is one of those networks that comes to mind. 
Unfortunately their source is not available. They allow you to use a SET 
RESPONSE MSG/NOTICE Granted, the aliasing '/***Serv somecommand' instead 
of having to use the old '/msg ***Serv somecomand' does make it easier 
but it's still nice to have a choice. There are a few other nice 
features with their services as well. Some that I do not see on any 
other service.

Is this possible?
TIA
From Craig at frostycoolslug.com  Sat Aug 27 08:25:24 2005
From: Craig at frostycoolslug.com (Craig McLure)
Date: Sat Aug 27 08:27:38 2005
Subject: [IRCServices Coding] ServBot Replies
In-Reply-To: <4310829C.9040200@verizon.net>
References: <4310829C.9040200@verizon.net>
Message-ID: <431085E4.1000702@frostycoolslug.com>

Anything is possible.. it just isn't easy.


Services uses notice() to send notices, however as far as i'm aware its 
also hard coded in send_raw()

A Module could use cb_set to capture and store the option, however in 
this case you would probably be better off modifying the user struct to 
store this (This also potentially means you will need to modify 
databases etc.)

As the FAQ states, IRCServices wasn't designed with this functionality, 
and conciquently, theres no real code to support it without making a few 
fundimental changes to the way services works.

Other than this, i can't see a way to change it.

/****************************************
  *     Craig "FrostyCoolSlug" McLure
  *       Craig@FrostyCoolSlug.com
  * InspIRCd   - http://www.inspircd.org
  * ChatSpike  - http://www.chatspike.net
  ****************************************/

Randall J. Berry wrote:
>    Hi All,
> First.. Yes I've read the FA*Q
> *
> 
> <--Begin Paste
> C.7. How can I make Services send replies using PRIVMSG (/msg) instead 
> of NOTICE?
> You can't. RFC 1459 (the IRC protocol definition) requires that all 
> automated clients send all replies using NOTICE rather than PRIVMSG, and 
> Services follows that requirement. If you want to change how Services 
> replies appear in your IRC client, change your client's settings.
> End Paste-->
> 
> I'd like to know how I can change the code to make ***Serv to reply in 
> PRIVMSG/NOTICE as per user request. I understand the reason for making 
> the default per RFC standard but I've seen some services that still use 
> MSG and some that allow the user to choose how they want the bot to 
> reply. Beyond IRC services is one of those networks that comes to mind. 
> Unfortunately their source is not available. They allow you to use a SET 
> RESPONSE MSG/NOTICE Granted, the aliasing '/***Serv somecommand' instead 
> of having to use the old '/msg ***Serv somecomand' does make it easier 
> but it's still nice to have a choice. There are a few other nice 
> features with their services as well. Some that I do not see on any 
> other service.
> 
> Is this possible?
> TIA
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> 

From unibg at unilans.net  Thu Sep 22 17:45:35 2005
From: unibg at unilans.net (=?Windows-1251?Q?=C8=E2=EE?= =?Windows-1251?Q?=C2=E0=F7=EA=EE=E2?=)
Date: Thu Sep 22 17:43:56 2005
Subject: [IRCServices Coding] RatBox support
Message-ID: <FaHz5Uxj.1127436335.0856290.unibg@unilans.net>

Hello, all,

I'm trying to create a protocol module for RatBox compatibility. I took
hybrid code and modified to support RatBox. So far, so good :) The souce
code I attach, generally WORKS. It connects to RatBox IRCD 2.0.11, you
can use the services. However I have some problems. 

I can't change topics with ChanServ when TOPICLOCK is set on a channel.
I read the RatBox Services code and found that "TB" is the right
command. However, when I use it I don't see anything in the log files
(services and ircd) and still nothing changes, topic is the same.

Can you point me out (probably obvious) my faults/mistakes ?

Thank you in advance.

    Ivo Vachkov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ratbox.c
Type: application/octet-stream
Size: 12907 bytes
Desc: not available
Url : http://lists.ircservices.za.net/pipermail/ircservices-coding/attachments/20050923/2da4384b/ratbox-0001.obj
From surreal.w00t at gmail.com  Sun Sep 25 16:45:29 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Sun Sep 25 16:46:18 2005
Subject: [IRCServices Coding] RatBox support
In-Reply-To: <FaHz5Uxj.1127436335.0856290.unibg@unilans.net>
References: <FaHz5Uxj.1127436335.0856290.unibg@unilans.net>
Message-ID: <43373699.3020307@gmail.com>

Seeing as nobody else has replied, I might ask the obvious.. have you 
made sure you are sending the parameters in the right order etc? I'm no 
expert with ratbox, but I'll have a look around and see if I can come up 
with something a little more helpful ;)

????????? wrote:
> Hello, all,
> 
> I'm trying to create a protocol module for RatBox compatibility. I took
> hybrid code and modified to support RatBox. So far, so good :) The souce
> code I attach, generally WORKS. It connects to RatBox IRCD 2.0.11, you
> can use the services. However I have some problems. 
> 
> I can't change topics with ChanServ when TOPICLOCK is set on a channel.
> I read the RatBox Services code and found that "TB" is the right
> command. However, when I use it I don't see anything in the log files
> (services and ircd) and still nothing changes, topic is the same.
> 
> Can you point me out (probably obvious) my faults/mistakes ?
> 
> Thank you in advance.
> 
>     Ivo Vachkov
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding

From surreal.w00t at gmail.com  Thu Sep 29 20:19:55 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Thu Sep 29 20:20:21 2005
Subject: [IRCServices Coding] Small thing in modules/nickserv/mail-auth.c
Message-ID: <433CAEDB.1070209@gmail.com>

Hi,

I was having a random browse through sourcecode (yes, I have nothing 
better to do..) and happened across do_clearauth.

I noticed that the readonly check is actually made _after_ processing 
the clearauth, perhaps it should be integrated up with the rest of the 
checks before doing clearauth? (Otherwise, what's the point of the 
notice, when it doesn't block anything?)

Ta,
w00t
From achurch at achurch.org  Fri Sep 30 12:29:19 2005
From: achurch at achurch.org (Andrew Church)
Date: Thu Sep 29 20:30:34 2005
Subject: [IRCServices Coding] Small thing in modules/nickserv/mail-auth.c
In-Reply-To: <433CAEDB.1070209@gmail.com>
Message-ID: <433cb154.13647@msgid.achurch.org>

>I noticed that the readonly check is actually made _after_ processing 
>the clearauth, perhaps it should be integrated up with the rest of the 
>checks before doing clearauth? (Otherwise, what's the point of the 
>notice, when it doesn't block anything?)

     This is correct behavior.  Readonly is only meant to block ordinary
user changes; services admins are allowed to change things as needed (and
get a warning in that case, as with CLEARAUTH).

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From surreal.w00t at gmail.com  Thu Sep 29 20:38:40 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Thu Sep 29 20:38:55 2005
Subject: [IRCServices Coding] Small thing in modules/nickserv/mail-auth.c
In-Reply-To: <433cb154.13647@msgid.achurch.org>
References: <433cb154.13647@msgid.achurch.org>
Message-ID: <433CB340.1010700@gmail.com>

Andrew Church wrote:
>      This is correct behavior.  Readonly is only meant to block ordinary
> user changes; services admins are allowed to change things as needed (and
> get a warning in that case, as with CLEARAUTH).

Hrm, ok. I had assumed readonly meant.. readonly :P
From achurch at achurch.org  Wed Nov 23 03:00:00 2005
From: achurch at achurch.org (Andrew Church)
Date: Tue Nov 22 10:01:27 2005
Subject: [IRCServices Coding] 5.1a0
Message-ID: <43835ce9.75014@msgid.achurch.org>

     Here it is, after months of blood, sweat and tears (or possibly
just a lot of slacking off): the first alpha release of Services 5.1.
The changes are, of course, too numerous to mention, but I've included
the rundown from the What's New file at the bottom of this announcement.
Download sites are as usual:

http://www.ircservices.za.net/download/testing/   (Japan)
ftp://ftp.esper.net/ircservices/testing/          (Western USA)

8bb6a7e6b6e01144f6b35f3344c0a581  ircservices-5.1a0.tar.gz
06151dc93fe7a521bed1d5761c674003  ircservices-5.1a0-1.i386.rpm
e7d5f2066879e4851db1cb6535f98e5c  ircservices_5.1a0-1_i386.deb

     Module developers should note that, among other things, database
handling has changed and the "save data" callback is gone (to save data
periodically outside of the standard database framework, set a timeout
using the timeout.c routines).  If you want to make your code compatible
with both 5.0 and 5.1, use something like:

#if MODULE_VERSION_CODE >= MODULE_VERSION(5,1,MODULE_VERSION_ALPHA,0)
    /* version 5.1 code */
#else
    /* version 5.0 code */
#endif

     Here's what I'm interesting in hearing about the new release:

- Bug reports, obviously.  In particular, the database loading/saving
  code has been completely rewritten, and the new file format will be
  implemented sometime over the next few alpha releases; it _should_
  work (knock on wood) but please keep an eye out for data getting
  corrupted, appearing out of nowhere, spontaneously combusting, etc.

- Feature suggestions.  As long as 5.1 is in alpha, I'm open to adding
  new features.  (But that doesn't mean I'll add everything and the
  kitchen sink!  FAQ Z.5 applies just as always.)

- Usability comments.  After ten years of development, I know Services
  inside and out, so I may not realize that some things aren't obvious
  to newcomers.  If you see anything that strikes you as odd or
  nonintuitive (whether new in this version or present since older
  versions), please let me know.

- Suggestions from OS porters--Linux distribution maintainers, FreeBSD
  ports people, whoever--on how I can make Services easier to use in OS
  distributions: file placement, compilation procedures, anything that
  you have to work around or patch to get Services to fit properly into
  your OS.  If you're not one of these people but you know one, please
  ask them for opinions.  (Before anybody suggests it, however, using
  autoconf is out of the question; I'm not touching that pile of rotten
  spaghetti with a ten-foot pole.)

     On a more serious note, I have one other, important announcement:
Services 5.1 is the last version of Services that I intend to release.
While I don't consider Services "complete"--software development is a
neverending task, and in any case users' needs change over time--I do
believe that it's time for me to move on to other things.  In fact, I
already devote a fair amount of my time to other software development
projects (such as the audio/video tool "transcode", for those who are
familiar with it), and I have other hobbies which I haven't been able
to pursue as much as I'd like.  I've also found that I personally use
IRC very infrequently these days, and that has inevitably lessened my
interest in continuing Services development as well.

     I certainly don't believe that IRC itself is a dead or obsolete
protocol, and I intend to document the inner workings of Services over
the next few months (or however long it takes) so that other developers
can pick up as easily as possible where I'm leaving off.  I will also
monitor the mailing lists for the near future and maintain Services 5.1
to the extent of fixing bugs and making other reasonably small changes.
In terms of major improvements and additions, however, 5.1.0 will be the
"final form", at least under my care, of Services for IRC Networks.

     That said, I expect 5.1 will go through a bunch of alpha and beta
iterations before it reaches release status, and I'll work at least as
hard as I always have to ensure that what comes out is as good as I can
make it.  I did, however, want to provide advance warning of my future
intentions.  Thank you all for your support over the years.

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

---------------------------------------------------------------------------

                                What's New
               =============================================
               Summaries of changes in new Services versions

Note: This is intended to highlight only the major changes between
      versions.  For a complete list of changes, see the "Changes" file.

------------
Version 5.1:
------------
Database handling, the one remaining aspect of Services which has remained
essentially unchanged since version 1.0, has finally undergone a fairly
significant redesign.  Rather than using specialized data load and save
routines tailored for the core Services pseudoclients, Services now
implements a generic database table system, which has the dual benefits of
separating the data storage system from the rest of Services (allowing
alternative storage methods to be implemented easily) and allowing third-
party modules and extensions to create their own non-volatile databases
without resorting to custom load/save routines.  The default database file
format has also been changed to be more future-proof and error-resilient
than the old format (which admittedly isn't saying much); see the
"upgrading" section of the manual for instructions on switching your
databases to the new format.
[FIXME: still in progress as of 5.1a0]

The often-criticized channel memo system has also been redesigned for this
version.  Instead of storing channel memos with the channel, memos are now
sent to the founder and all users on the channel with a particular access
level (by default level 100, or SOP level).  These memos are distinguished
from ordinary memos by text that says "(for #channel)" when reading the
memo.  As a result of this change, users will be notified about new channel
memos in the same way as ordinary user-to-user memos.

NOTICE: When loading databases from version 5.0 or earlier, all channel
        memos will be deleted.

Encryption support has also been improved.  Encryption is no longer an
all-or-nothing affair; the encryption method is stored with each password,
so that enabling or disabling encryption will have no effect on passwords
that were previously set.  The "encryption/unix-crypt" module has been
added, allowing the use of the Unix crypt() function to encrypt passwords.

The NickServ and ChanServ SENDPASS commands added in version 5.0 have been
removed in favor of the new NickServ REAUTH command.  This command
generates an authentication code which the user can use once to identify to
their nickname in place of the password, and then change the password as
needed.  Channel passwords can always be changed by the founder after
nickname identification, rendering ChanServ SENDPASS unnecessary.

Long LIST/VIEW responses are now handled more cleanly.  Except for NickServ
ACCESS LIST (since nickname access lists are generally short) and MemoServ
LIST (since memos are numbered), every list now includes an "end of list"
message indicating both the number of entries displayed and the total
number of entries in the list; the configuration directive ListMax,
replacing NSListMax and CSListMax, sets the maximum number of entries
displayed for any of these commands.  It is also possible to skip a certain
number of entries by adding a "+NNN" after the command, allowing all of the
entries in a long list to be viewed bit by bit.

At the development level, handling of module compilation has been improved,
allowing third-party modules to be simply "dropped in" without requiring
changes to Makefiles or other Services distribution files.  An extension
interface has been added to Services' multilingual support as well,
allowing modules to add their own language strings and load their own
language files.

Other changes:
  + Notices are now sent to the user when sending of a mail authentication
        code message fails.  (However, errors after the message has been
        handed off to the mail server cannot be detected.)
  + A new configuration directive, NSRejectEmail, now allowed selected
        E-mail addresses to be rejected by the NickServ REGISTER command.
  + NickServ INFO will now indicate when a nickname's user is using a
        different linked nickname if the nickname group's PRIVATE option
        is not set.
  + NickServ now has a RESTOREMAIL command (in the nickserv/mail-auth
        module), which allows a user to restore their nickname's last
        authenticated E-mail address if, for example, SET EMAIL is used
        with an incorrect address.
  + NickServ SET/UNSET by Services administrators for others' nicknames is
        now done by putting a "!" before the nick to avoid ambiguity; for
        example, "SET !nick NOEXPIRE ON" instead of "SET nick NOEXPIRE ON".
  + ChanServ ACCESS now includes a LISTLEVEL subcommand to list access
        entries with a given level or within a given level range.
  + ChanServ AKICK and MemoServ IGNORE now support matching by IP address
        (on servers which support client IP address information).
  + ChanServ OP, VOICE, and similar commands can now be used with multiple
        nicknames.
  + MemoServ now has a RENUMBER command to remove "holes" in the memo
        number sequence.
  + MemoServ FORWARD now sends all selected memos in a single E-mail
        message, rather than sending each memo in a separate message.
  + OperServ AKILL and related commands now have a CHECK subcommand which
        can be used to find all masks that match a given user/hostname.
  + SQlines are no longer applied to IRC operators during Services startup
        or netjoins if the IRC protocol in use supports sending user modes
        with the NICK message.  This currently includes the bahamut, hybrid,
        monkey, ptlink, trircd, and unreal protocol modules.
  + The ignore system has been redesigned, and now keeps better track of
        how much load each user is putting on Services.  The ignorance
        threshold can be fine-tuned via the configuration file.
  + A new "unsorted list" mode has been added to improve Services'
        performance on large networks.  By giving the -no-sorted-list
        option to the configure script, Services will not try to keep
        nicknames and channels in alphabetical order; this means that
        commands such as NickServ LIST will no longer return nicknames in
        order, but Services will run significantly faster.
  * ChanServ DROP now behaves like NickServ DROP: dropping a channel now
        requires the channel password to be entered with the DROP command,
        and DROPCHAN has been added as a separate command for Services
        administrators to drop arbitrary channels.
  * The ChanServ ACCESS, XOP, and AKICK commands no longer use entry
        numbers; the DEL and LIST subcommands now work with nicknames
        (hostmasks for the AKICK command) only.
  * The binary distributions (RPM and Debian packages) now install into
        /opt/ircservices and /var/opt/ircservices, rather than /usr/sbin
        and /usr/lib/ircservices.
  * Tab characters are no longer used (or allowed) in the source code.
  - The deprecated nickserv/oldlink module, which provided support for the
        format of the LINK command used in version 4 of Services, has been
        removed.
  - Support for the "channel owner" mode present in the PTlink (+a),
        trircd (+u), and Unreal (+q) IRC servers has been removed, as there
        are too many differing opinions on its proper use.
  - Language support for Italian and Portuguese has been removed, due to
        the lack of volunteers to maintain them.
  - Support for old versions of GCC (anything before GCC 3.2) has been
        removed.
Configuration file changes:
  + IncludeFile has been added to allow configuration directives to be
        split up into multiple files, and may be used in both
        ircservices.conf and modules.conf.
  + LoadLanguageText (ircservices.conf) has been added to allow replacement
        of Services text strings at runtime.
  + NSRejectEmail (module nickserv/main) has been added to allow rejection
        of selected E-mail addresses at nicknaem registration time.
  + NSSetEmailDelay (module nickserv/main) has been added to enforce a
        delay between consecutive uses of the SET EMAIL command, thereby
        reducing the potential for sending mailbombs.
  + CSDefModeLock (module chanserv/main) has been added to allow the
        default mode lock for newly registered channels to be changed.
  + MSExpireDelay (module memoserv/main) has been added to allow memo
        expiration to be delayed until a certain time after the memo is
        first read.
  + MaxMessages (module mail/main) has been added to allow a limit to be
        placed on the total number of messages in transit.
  * ListMax (ircservices.conf) has been added in place of NSListMax and
        CSListMask to set a limit on the number of entries displayed for
        all LIST-like commands.
  * WallAdminPrivs (ircservices.conf) has been added in place of
        WallGetpass and WallSetpass to cause a WALLOPS/GLOBOPS to be sent
        on all NickServ and ChanServ commands that use Services
        administrator privileges.
  * The database name configuration directives (NickServDB, ChanServDB,
        etc.) have been moved from the various pseudoclient module sections
        to the database/version4 module section, and now explicitly specify
        filenames.
  - The nickserv/sendpass and chanserv/sendpass modules (and therefore
        their respective configuration sections) have been removed.
  - CSAutokickReason (module chanserv/main) has been removed, as the
        built-in reason prefix "AKICK by <nick>" makes it unnecessary.
  - MSExpireUnread (module memoserv/main) has been removed, since it
        results in silent data loss.
  - MSNotifyAll (module memoserv/main) has been removed, since it is
        required for channel memos.  MemoServ will now always behave as if
        MSNotifyAll was set.
  - MaxSockets (module mail/smtp) has been removed, since MaxMessages now
        performs the same function.
From achurch at achurch.org  Wed Nov 23 03:16:52 2005
From: achurch at achurch.org (Andrew Church)
Date: Tue Nov 22 10:19:18 2005
Subject: [IRCServices Coding] Mailing list issues
Message-ID: <4383611a.75045@msgid.achurch.org>

     Just a quick note:  I've had a couple of reports recently of people
not being able to send mail to the list, getting an error back from the
mail server instead.  I'm looking into more permanent solutions, but in the
meantime, if you encounter such an error, please send your message to me
instead and I'll forward it to the list.

     Apologies for the inconvenience.

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From Craig at frostycoolslug.com  Tue Nov 22 10:25:28 2005
From: Craig at frostycoolslug.com (Craig McLure)
Date: Tue Nov 22 10:25:32 2005
Subject: [IRCServices Coding] 5.1a0
In-Reply-To: <43835ce9.75014@msgid.achurch.org>
References: <43835ce9.75014@msgid.achurch.org>
Message-ID: <43836298.7030404@frostycoolslug.com>

Just like to say congrats on this, it's certainly been a long time
coming. Fingers crossed alpha/beta testing for 5.1 will be as smooth and
quick as alpha 5.0 was. (For stability reasons we won't be testing 5.1
on ChatSpike, but i'll try to set up a test net which our users can play
on, this should help :)).

Thanks again for the hard work and effort you put into services, it's
greatly appreciated :)

Andrew Church wrote:
> More Stuff than usual :D

From stratus at blazeirc.net  Tue Nov 22 10:45:16 2005
From: stratus at blazeirc.net (Jim Stratus)
Date: Tue Nov 22 10:45:40 2005
Subject: [IRCServices Coding] 5.1a0
References: <43835ce9.75014@msgid.achurch.org>
Message-ID: <004201c5ef94$e21a4d60$c2db7286@noteryan>

Congratulations Andy. You've done so much for our IRC Networks and have 
provided a wonderful set of services for us. It is probably good for you to 
move on and do something else in your life now. You've made a great 
contribution here, and now I am sure you will contribute greatly elsewhere 
as well. You may also save yourself from going completely crazy this way :D

Jim Stratus
BlazeIRC Network
www.blazeirc.net
----- Original Message ----- 
From: "Andrew Church" <achurch@achurch.org>
To: "serv-coding" <ircservices-coding@ircservices.esper.net>
Sent: Tuesday, November 22, 2005 11:00 AM
Subject: [IRCServices Coding] 5.1a0


>     Here it is, after months of blood, sweat and tears (or possibly
> just a lot of slacking off): the first alpha release of Services 5.1.
> The changes are, of course, too numerous to mention, but I've included
> the rundown from the What's New file at the bottom of this announcement.
> Download sites are as usual:
>
> http://www.ircservices.za.net/download/testing/   (Japan)
> ftp://ftp.esper.net/ircservices/testing/          (Western USA)
>
> 8bb6a7e6b6e01144f6b35f3344c0a581  ircservices-5.1a0.tar.gz
> 06151dc93fe7a521bed1d5761c674003  ircservices-5.1a0-1.i386.rpm
> e7d5f2066879e4851db1cb6535f98e5c  ircservices_5.1a0-1_i386.deb
>
>     Module developers should note that, among other things, database
> handling has changed and the "save data" callback is gone (to save data
> periodically outside of the standard database framework, set a timeout
> using the timeout.c routines).  If you want to make your code compatible
> with both 5.0 and 5.1, use something like:
>
> #if MODULE_VERSION_CODE >= MODULE_VERSION(5,1,MODULE_VERSION_ALPHA,0)
>    /* version 5.1 code */
> #else
>    /* version 5.0 code */
> #endif
>
>     Here's what I'm interesting in hearing about the new release:
>
> - Bug reports, obviously.  In particular, the database loading/saving
>  code has been completely rewritten, and the new file format will be
>  implemented sometime over the next few alpha releases; it _should_
>  work (knock on wood) but please keep an eye out for data getting
>  corrupted, appearing out of nowhere, spontaneously combusting, etc.
>
> - Feature suggestions.  As long as 5.1 is in alpha, I'm open to adding
>  new features.  (But that doesn't mean I'll add everything and the
>  kitchen sink!  FAQ Z.5 applies just as always.)
>
> - Usability comments.  After ten years of development, I know Services
>  inside and out, so I may not realize that some things aren't obvious
>  to newcomers.  If you see anything that strikes you as odd or
>  nonintuitive (whether new in this version or present since older
>  versions), please let me know.
>
> - Suggestions from OS porters--Linux distribution maintainers, FreeBSD
>  ports people, whoever--on how I can make Services easier to use in OS
>  distributions: file placement, compilation procedures, anything that
>  you have to work around or patch to get Services to fit properly into
>  your OS.  If you're not one of these people but you know one, please
>  ask them for opinions.  (Before anybody suggests it, however, using
>  autoconf is out of the question; I'm not touching that pile of rotten
>  spaghetti with a ten-foot pole.)
>
>     On a more serious note, I have one other, important announcement:
> Services 5.1 is the last version of Services that I intend to release.
> While I don't consider Services "complete"--software development is a
> neverending task, and in any case users' needs change over time--I do
> believe that it's time for me to move on to other things.  In fact, I
> already devote a fair amount of my time to other software development
> projects (such as the audio/video tool "transcode", for those who are
> familiar with it), and I have other hobbies which I haven't been able
> to pursue as much as I'd like.  I've also found that I personally use
> IRC very infrequently these days, and that has inevitably lessened my
> interest in continuing Services development as well.
>
>     I certainly don't believe that IRC itself is a dead or obsolete
> protocol, and I intend to document the inner workings of Services over
> the next few months (or however long it takes) so that other developers
> can pick up as easily as possible where I'm leaving off.  I will also
> monitor the mailing lists for the near future and maintain Services 5.1
> to the extent of fixing bugs and making other reasonably small changes.
> In terms of major improvements and additions, however, 5.1.0 will be the
> "final form", at least under my care, of Services for IRC Networks.
>
>     That said, I expect 5.1 will go through a bunch of alpha and beta
> iterations before it reaches release status, and I'll work at least as
> hard as I always have to ensure that what comes out is as good as I can
> make it.  I did, however, want to provide advance warning of my future
> intentions.  Thank you all for your support over the years.
>
>  --Andrew Church
>    achurch@achurch.org
>    http://achurch.org/
>
> ---------------------------------------------------------------------------
>
>                                What's New
>               =============================================
>               Summaries of changes in new Services versions
>
> Note: This is intended to highlight only the major changes between
>      versions.  For a complete list of changes, see the "Changes" file.
>
> ------------
> Version 5.1:
> ------------
> Database handling, the one remaining aspect of Services which has remained
> essentially unchanged since version 1.0, has finally undergone a fairly
> significant redesign.  Rather than using specialized data load and save
> routines tailored for the core Services pseudoclients, Services now
> implements a generic database table system, which has the dual benefits of
> separating the data storage system from the rest of Services (allowing
> alternative storage methods to be implemented easily) and allowing third-
> party modules and extensions to create their own non-volatile databases
> without resorting to custom load/save routines.  The default database file
> format has also been changed to be more future-proof and error-resilient
> than the old format (which admittedly isn't saying much); see the
> "upgrading" section of the manual for instructions on switching your
> databases to the new format.
> [FIXME: still in progress as of 5.1a0]
>
> The often-criticized channel memo system has also been redesigned for this
> version.  Instead of storing channel memos with the channel, memos are now
> sent to the founder and all users on the channel with a particular access
> level (by default level 100, or SOP level).  These memos are distinguished
> from ordinary memos by text that says "(for #channel)" when reading the
> memo.  As a result of this change, users will be notified about new 
> channel
> memos in the same way as ordinary user-to-user memos.
>
> NOTICE: When loading databases from version 5.0 or earlier, all channel
>        memos will be deleted.
>
> Encryption support has also been improved.  Encryption is no longer an
> all-or-nothing affair; the encryption method is stored with each password,
> so that enabling or disabling encryption will have no effect on passwords
> that were previously set.  The "encryption/unix-crypt" module has been
> added, allowing the use of the Unix crypt() function to encrypt passwords.
>
> The NickServ and ChanServ SENDPASS commands added in version 5.0 have been
> removed in favor of the new NickServ REAUTH command.  This command
> generates an authentication code which the user can use once to identify 
> to
> their nickname in place of the password, and then change the password as
> needed.  Channel passwords can always be changed by the founder after
> nickname identification, rendering ChanServ SENDPASS unnecessary.
>
> Long LIST/VIEW responses are now handled more cleanly.  Except for 
> NickServ
> ACCESS LIST (since nickname access lists are generally short) and MemoServ
> LIST (since memos are numbered), every list now includes an "end of list"
> message indicating both the number of entries displayed and the total
> number of entries in the list; the configuration directive ListMax,
> replacing NSListMax and CSListMax, sets the maximum number of entries
> displayed for any of these commands.  It is also possible to skip a 
> certain
> number of entries by adding a "+NNN" after the command, allowing all of 
> the
> entries in a long list to be viewed bit by bit.
>
> At the development level, handling of module compilation has been 
> improved,
> allowing third-party modules to be simply "dropped in" without requiring
> changes to Makefiles or other Services distribution files.  An extension
> interface has been added to Services' multilingual support as well,
> allowing modules to add their own language strings and load their own
> language files.
>
> Other changes:
>  + Notices are now sent to the user when sending of a mail authentication
>        code message fails.  (However, errors after the message has been
>        handed off to the mail server cannot be detected.)
>  + A new configuration directive, NSRejectEmail, now allowed selected
>        E-mail addresses to be rejected by the NickServ REGISTER command.
>  + NickServ INFO will now indicate when a nickname's user is using a
>        different linked nickname if the nickname group's PRIVATE option
>        is not set.
>  + NickServ now has a RESTOREMAIL command (in the nickserv/mail-auth
>        module), which allows a user to restore their nickname's last
>        authenticated E-mail address if, for example, SET EMAIL is used
>        with an incorrect address.
>  + NickServ SET/UNSET by Services administrators for others' nicknames is
>        now done by putting a "!" before the nick to avoid ambiguity; for
>        example, "SET !nick NOEXPIRE ON" instead of "SET nick NOEXPIRE ON".
>  + ChanServ ACCESS now includes a LISTLEVEL subcommand to list access
>        entries with a given level or within a given level range.
>  + ChanServ AKICK and MemoServ IGNORE now support matching by IP address
>        (on servers which support client IP address information).
>  + ChanServ OP, VOICE, and similar commands can now be used with multiple
>        nicknames.
>  + MemoServ now has a RENUMBER command to remove "holes" in the memo
>        number sequence.
>  + MemoServ FORWARD now sends all selected memos in a single E-mail
>        message, rather than sending each memo in a separate message.
>  + OperServ AKILL and related commands now have a CHECK subcommand which
>        can be used to find all masks that match a given user/hostname.
>  + SQlines are no longer applied to IRC operators during Services startup
>        or netjoins if the IRC protocol in use supports sending user modes
>        with the NICK message.  This currently includes the bahamut, 
> hybrid,
>        monkey, ptlink, trircd, and unreal protocol modules.
>  + The ignore system has been redesigned, and now keeps better track of
>        how much load each user is putting on Services.  The ignorance
>        threshold can be fine-tuned via the configuration file.
>  + A new "unsorted list" mode has been added to improve Services'
>        performance on large networks.  By giving the -no-sorted-list
>        option to the configure script, Services will not try to keep
>        nicknames and channels in alphabetical order; this means that
>        commands such as NickServ LIST will no longer return nicknames in
>        order, but Services will run significantly faster.
>  * ChanServ DROP now behaves like NickServ DROP: dropping a channel now
>        requires the channel password to be entered with the DROP command,
>        and DROPCHAN has been added as a separate command for Services
>        administrators to drop arbitrary channels.
>  * The ChanServ ACCESS, XOP, and AKICK commands no longer use entry
>        numbers; the DEL and LIST subcommands now work with nicknames
>        (hostmasks for the AKICK command) only.
>  * The binary distributions (RPM and Debian packages) now install into
>        /opt/ircservices and /var/opt/ircservices, rather than /usr/sbin
>        and /usr/lib/ircservices.
>  * Tab characters are no longer used (or allowed) in the source code.
>  - The deprecated nickserv/oldlink module, which provided support for the
>        format of the LINK command used in version 4 of Services, has been
>        removed.
>  - Support for the "channel owner" mode present in the PTlink (+a),
>        trircd (+u), and Unreal (+q) IRC servers has been removed, as there
>        are too many differing opinions on its proper use.
>  - Language support for Italian and Portuguese has been removed, due to
>        the lack of volunteers to maintain them.
>  - Support for old versions of GCC (anything before GCC 3.2) has been
>        removed.
> Configuration file changes:
>  + IncludeFile has been added to allow configuration directives to be
>        split up into multiple files, and may be used in both
>        ircservices.conf and modules.conf.
>  + LoadLanguageText (ircservices.conf) has been added to allow replacement
>        of Services text strings at runtime.
>  + NSRejectEmail (module nickserv/main) has been added to allow rejection
>        of selected E-mail addresses at nicknaem registration time.
>  + NSSetEmailDelay (module nickserv/main) has been added to enforce a
>        delay between consecutive uses of the SET EMAIL command, thereby
>        reducing the potential for sending mailbombs.
>  + CSDefModeLock (module chanserv/main) has been added to allow the
>        default mode lock for newly registered channels to be changed.
>  + MSExpireDelay (module memoserv/main) has been added to allow memo
>        expiration to be delayed until a certain time after the memo is
>        first read.
>  + MaxMessages (module mail/main) has been added to allow a limit to be
>        placed on the total number of messages in transit.
>  * ListMax (ircservices.conf) has been added in place of NSListMax and
>        CSListMask to set a limit on the number of entries displayed for
>        all LIST-like commands.
>  * WallAdminPrivs (ircservices.conf) has been added in place of
>        WallGetpass and WallSetpass to cause a WALLOPS/GLOBOPS to be sent
>        on all NickServ and ChanServ commands that use Services
>        administrator privileges.
>  * The database name configuration directives (NickServDB, ChanServDB,
>        etc.) have been moved from the various pseudoclient module sections
>        to the database/version4 module section, and now explicitly specify
>        filenames.
>  - The nickserv/sendpass and chanserv/sendpass modules (and therefore
>        their respective configuration sections) have been removed.
>  - CSAutokickReason (module chanserv/main) has been removed, as the
>        built-in reason prefix "AKICK by <nick>" makes it unnecessary.
>  - MSExpireUnread (module memoserv/main) has been removed, since it
>        results in silent data loss.
>  - MSNotifyAll (module memoserv/main) has been removed, since it is
>        required for channel memos.  MemoServ will now always behave as if
>        MSNotifyAll was set.
>  - MaxSockets (module mail/smtp) has been removed, since MaxMessages now
>        performs the same function.
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding 

From surreal.w00t at gmail.com  Tue Nov 22 12:59:27 2005
From: surreal.w00t at gmail.com (w00t)
Date: Tue Nov 22 12:59:37 2005
Subject: [IRCServices Coding] 5.1a0
In-Reply-To: <004201c5ef94$e21a4d60$c2db7286@noteryan>
References: <43835ce9.75014@msgid.achurch.org>
        <004201c5ef94$e21a4d60$c2db7286@noteryan>
Message-ID: <b19eae4e0511221259k163ea459r5bc8c0c3f35a2c8a@mail.gmail.com>

I've not been around as long as some, but your contributions have been
great Andrew. Thanks for your work over the years, and here's to more
years of Services use to come.

[I'll reply in full a bit later on, pressed for time atm.]
From surreal.w00t at gmail.com  Wed Nov 23 00:33:28 2005
From: surreal.w00t at gmail.com (w00t)
Date: Thu Nov 24 06:41:10 2005
Subject: [IRCServices Coding] 5.1a0
In-Reply-To: <b19eae4e0511221259k163ea459r5bc8c0c3f35a2c8a@mail.gmail.com>
References: <43835ce9.75014@msgid.achurch.org>
        <004201c5ef94$e21a4d60$c2db7286@noteryan>
        <b19eae4e0511221259k163ea459r5bc8c0c3f35a2c8a@mail.gmail.com>
Message-ID: <b19eae4e0511230033j4404b7cgf6116252987e9761@mail.gmail.com>

http://www.ircservices.za.net/download/testing/   (Japan)

^-- Get a 404 on that link, presume you mean ircservices.esper.net? ;)
From achurch at achurch.org  Fri Nov 25 00:20:54 2005
From: achurch at achurch.org (Andrew Church)
Date: Thu Nov 24 07:21:23 2005
Subject: [IRCServices Coding] 5.1a0
In-Reply-To: <b19eae4e0511230033j4404b7cgf6116252987e9761@mail.gmail.com>
Message-ID: <4385da6c.31656@msgid.achurch.org>

>http://www.ircservices.za.net/download/testing/   (Japan)
>
>^-- Get a 404 on that link, presume you mean ircservices.esper.net? ;)

     Oops, that's correct.  Silly me.  I really ought to get around to
doing something about that...

  --Andrew Church
    achurch@achurch.org
    http://achurch.org/
From kfiresun at ix.netcom.com  Thu Nov 24 10:07:55 2005
From: kfiresun at ix.netcom.com (Kelmar K. Firesun)
Date: Thu Nov 24 10:08:02 2005
Subject: [IRCServices Coding] 5.1a0
In-Reply-To: <b19eae4e0511230033j4404b7cgf6116252987e9761@mail.gmail.com>
References: <43835ce9.75014@msgid.achurch.org>  <004201c5ef94$e21a4d60$c2db7286@noteryan>       <b19eae4e0511221259k163ea459r5bc8c0c3f35a2c8a@mail.gmail.com>
        <b19eae4e0511230033j4404b7cgf6116252987e9761@mail.gmail.com>
Message-ID: <4386017B.4050608@ix.netcom.com>

I was able to get a copy of off EsperNET's ftp server:
ftp://ftp.esper.net/ircservices/testing/

Kelmar Fireusn

w00t wrote:
> http://www.ircservices.za.net/download/testing/   (Japan)
> 
> ^-- Get a 404 on that link, presume you mean ircservices.esper.net? ;)
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices-coding
> 

From surreal.w00t at gmail.com  Fri Dec 30 03:16:00 2005
From: surreal.w00t at gmail.com (Robin Burchell)
Date: Fri Dec 30 03:14:22 2005
Subject: [IRCServices Coding] MS IGNORE
Message-ID: <43B516F0.7030900@gmail.com>

Hi,

This should possibly have gone to -general, but regardless.

MS IGNORE, if used on a nick target *should* ignore all memos from that 
account to a target, which it probably does. However, it does not appear 
to ignore memos from a linked nickname or something, as it seems to have 
gone through...

-MemoServ- Ignore list:
-MemoServ-     igor

-MemoServ- Memo 2 from pingout (Dec 29 23:47:39 2005 UTC).  To delete, 
type: /msg MemoServ DEL 2

I can't confirm this was a linked nick, and I probably should RTFS to 
check first, but please excuse me being naughty as I'm in a little of a 
hurry. Naturally, IGNORE on a u@h would eliminate this problem.