[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