> Kent Landfield (kent_at_landfield.com)
> 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
--makeres.out--
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.ohypermail.o print.o base64.o printfile.o uudecode.o chmod 0755 hypermail
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 ftp.some.site:/pub/filename 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