Re: Getting started

From: Kent Landfield <>
Date: Thu, 23 Apr 1998 11:34:55 -0500 (CDT)
Message-Id: <>

# I'm a bit confused by the above statement; is it necessary to
# reprocess all 4.5M every time Hypermail is run? Does it not keep an
# on-disk database, and update things incrementally? Anyway, I'm the
# guy who wrote Pipermail, and will contribute a brief discussion of
# Pipermail's structure that hopefully will prove helpful.

In my case it is the incremental overhead of having to load perl as is done with some converters.

# At bottom, Pipermail is just a few abstract base classes:
# Database, Article, and a class representing an archiver. The base
# classes contain the logic of adding articles to an archive, threading
# them, writing index files, etc. None of the actual formatting of
# messages or indexes is specified in the base classes; I've written a
# set of classes which mimic Hypermail, and which can be subclassed
# further, but you could also write your own from scratch and produce
# something which looked nothing like Hypermail at all. This is because
# I looked around and noticed how many hacked versions of Hypermail
# there were, and wanted something that would be easily extensible.

:) I can agree with this. ;) I'm very guilty of taking the easy way out when I was just hacking hypermail for me. Instead of implementing HTML page format templates, I created a customied {list}_print.c that handled that. This is NOT the approach that should be taken for a general purpose solution but it was easy at the time for personal needs.

# So, for example, the archiver class has a get_archives()
# method that's passed the article, and returns a list naming the
# indexes where the article should be archived. You can therefore file
# a message into several indexes, or none at all; a hypothetical
# archiver for linux-kernel could check if a message contains a patch,
# and return ['linux-kernel', 'posted-patches'] if it did. Or
# get_archives() could check if the subject matched ^subscribe\s, and
# return an empty list, discarding the message. It's only limited by
# how much work you want to do in that function.

This is a great idea! I've wanted to have alternate indices for specific mailing lists.

# Similarly, there are methods which are supposed to write the
# header of an index, the footer, and a single entry, to convert
# a message to HTML, write a table of contents listing all the archives,
# and so forth. It hasn't proven difficult to produce a customized
# interface on top of the Hypermail-lookalike classes, such as the SIG
# archives at

Yep. Sounds like my approach to hypermail. ;)

It is clear that the issues are the same, the only differences is in the implementation and selection of supported features.

Kent Landfield                        Phone: 1-817-545-2502             
Please send comp.sources.misc related mail to
Search the Usenet Hypertext FAQ Archive at
Received on Thu 23 Apr 1998 06:35:11 PM GMT

This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:10 AM GMT GMT