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