Re: Thoughts on what's next.

From: <>
Date: Tue, 09 Jun 98 15:07:53 -0500
Message-Id: <>

> Kent Landfield (
> Mon, 8 Jun 1998 13:34:28 -0500 (CDT)

> We are at a point where most everything has been merged and people are
> starting to play with the new version. (I even got Craig Summerhill's and
> Roy Tennant's suggestions in.) There are still some patches I need review
> again for possible integration but at this point it's time to think about
> what's next. The following is list of lists of ramblings. Feel free to
> jump in on any one or all. ;)

> ============
> Comparisons:
> ============

> It was suggested earlier that we look at the features that mhonarc has
> that hypermail might need. This is what I see as *real* differences.

> - Support variant mail folders types. Hypermail supports only UUCP
> style mailboxes. We could create an archive of converters somewhere
> so people could grab them when they need them.

> - With the MIME model, you can extend MHonArc to handle content-types
> that it does not support by default. The granularity is better.

> - Page customization. A real difference. Need to be able to give the user
> complete control on how pages are formatted, including the use of frames.

> - Windows/NT (and all the other platforms that perl runs on).
> A Windows/NT port has been asked for a few times in the last month.
> (When suggested to try mhonarc two said they had and it was too slow.)

Hypermail 2.0b2 built without real problems on NT using CygWin-b19

cd src; make all CC="gcc" CFLAGS="-g -O2" \

        cgidir="/httpd/cgi-bin" bindir="/usr/local/bin"

gcc -c -g -O2 file.c
gcc -c -g -O2 mem.c
gcc -c -g -O2 string.c
gcc -c -g -O2 parse.c
gcc -c -g -O2 struct.c
gcc -c -g -O2 date.c
gcc -c -g -O2 hypermail.c
gcc -c -g -O2 print.c
gcc -c -g -O2 base64.c
gcc -c -g -O2 printfile.c
gcc -c -g -O2 uudecode.c
gcc -o hypermail -g -O2 file.o mem.o string.o parse.o struct.o date.o
hypermail.o print.o base64.o printfile.o uudecode.o chmod 0755 hypermail
chmod: hypermail: No such file or directory make[1]: *** [hypermail] Error 1
make: *** [hypermail] Error 2

A little fiddling with the latest autoconf version with the executable extension should give an completely clean build

Running this over an elm mail-folder of CIAC announcements forwarded to me by a colleague worked fine as far as I can see (with Netscape).

> There are many others that are implementation based but don't seem to be
> functionality based. FWIW.

> ==================
> Important Things:
> ==================

> - Add locking to the archive so there is no race conditions and only a
> single message is processed at a time. Subsequent arriving messages
> would queue waiting completion... At the present time it is possible
> to have two, three, ... hypermail processes trying to update the same
> archive. This can cause real problems on a high traffic list that needs
> near-real time updating.

> - Add URL sanity validation routines to assure that only valid
> URLs are generated. This will also look for other links besides
> just listed URLs. (convert into a URL)

> - MIME support and all it implies (_real_ close but still a little to go)

> o Need to have the enclosure filenames tied somehow to the file it is
> linked from for removal and overwrite updates.

> o Have the MIME decoding ignore multipart/alternative and have it use
> a configured default (such as plain/text) as the primary method
> (dropping the redundant alternatives on the floor).


> =============
> Index Issues:
> =============

> - Generate different types of Index pages. Author, Subject, Thread, Date
> are currently support. What other index types might be wanted ? Message
> number ? Via message ID ?

    Look at critmail's more parameterized index creation if not already     merged. As a reader of hypermail indexed lists I wonder how many people     use more than the thread index now? What do the web stats say?     See also critmail's changes to use ' " "' in place of repeated subject     lines. This was in response to lists with long threads where the subject     line didn't change but the nesting got quite deep.

    I fiddled critmail so that the dates on the author & subject indices     would be ISO format (1999-12-31) and as a fixed width field precede     the variable length author or subject. I suspect few people care     about message times to greater than a day accuracy - especially when     more than a day or two old.

> - Add ability to breakup index pages into multiple pages

> o Limit by # of messages and by hour/day/week/month/size

> o Make subfolders?

> - Add links to message attachments on index pages ?

> ============
> Date Issues:
> ============

> - Date Normalization ?

    A can of worms with more people forced onto WINTEL email systems     with questionable TimeZone settings.

> - Check for dates not containing ":"

> - Check for date values that are not padded with a "0" on the left

> - Date sorting needs to be more robust

> o Allow for very old years

> o Allow for years > current year

> o Timezone conversion

      Some of this (ignoring timezones though) has been done in critmail.

> - Archiving by date sent versus date received ?

> ========
> General:
> ========

> - Add complete capabilites to format HTML including the ability to
> provide FRAMES support ?

    XML & the bibliographic standard support

> - Systems portability:

> o Testing on other Unix platforms

> o Porting to Windows/NT

> - Automated regression test suite.

    makes portability testing much easier.

> - Need to create a library of hypermail functions so that other utilities
> can be generated without making things real ugly. (i.e. removal, other
> indexing.)

> - Verify Year 2000 compliance

    Think that the original RFC 822 forces 2-digit years. I note that elm     mailfiles use "Thu Jan 19 13:39:29 1995" style on their '^From '     lines.

> - A better icon for hypermail!

> =================
> Parsing and Code:
> =================

> - Should recognize and parse indented HTML tags

> - In parsing header fields, check for extra spaces, tabs, etc.

> - Check for zero-length headers

> - Make sure "sort by..." groups all messages in same thread

> - Add sort by "in reply to" as well

> - No fixed string limits

> - No fixed message limits

> - Performance enhancements for dealing with large archives. Profiling the
> code to see where the time is being spent and speed it up.

    Some critmail changes may be relevant.

> ==============
> Documentation:
> ==============

> - Real documentation on Archiving the Hypermail way.

> - Description document as to how things work internally.

> --------------------

> These are on the table as to what should be done next. The Important ones
> might be a starting point... ;) Comments ? What is it that you need the
> most ?
Received on Tue 09 Jun 1998 03:02:31 PM GMT

This archive was generated by hypermail 2.2.0 : Thu 22 Feb 2007 07:33:49 PM GMT GMT