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" To: 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" >To: >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: 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: 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: References: 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: 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 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: 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: 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: 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 ) 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 ) 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 -------------- 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: References: 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 ) > 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 ) > 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 > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------ > 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: 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 ) 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 ) 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/> > >------=_Part_6963_25044273.1124706341036 >Content-Type: text/html; 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 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:
>
0pt 0pt 0.8ex; padding-left: 1ex; background-color: rgb(204, 204, 204);" c= >lass=3D"gmail_quote">*** SoCkX (~a@> >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
>
0pt 0pt 0.8ex; padding-left: 1ex;" class=3D"gmail_quote">ckground-color: rgb(204, 204, 204);">*** SoCkX (~a@069B23.iplei.pt"> >NiX-B9069B23.iplei.pt) has joined #somechan
nd-color: rgb(204, 204, 204);"> > * ChanServ sets mod= >e: +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 firs= >t 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
>
> >------=_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: <4309b81c.07004@msgid.achurch.org> Message-ID: 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 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: 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: 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: References: 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 " 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" To: "serv-coding" 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 " 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: 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: References: <43835ce9.75014@msgid.achurch.org> <004201c5ef94$e21a4d60$c2db7286@noteryan> Message-ID: 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: 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: References: <43835ce9.75014@msgid.achurch.org> <004201c5ef94$e21a4d60$c2db7286@noteryan> 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.