[IRCServices Coding] 5.1a0

Andrew Church achurch at achurch.org
Wed Nov 23 03:00:00 PST 2005


     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.