Earl Hood said:
I've fixed the mailing processing code so MIME processing will work
under Perl 5. I finally got access to a machine with perl 5.001m
on it to test things out. Currently, this is what I've done:
o mhonarc now will eval require statements. This way
mhonarc can cleanup properly if a require fails.
A nice-to-have feature would be to do the eval of filters on demand.
(auto-load in perl5. I don't know if it easy/possible in perl4.)
o Reorganized mhonarc code to reflect changes in readmail.pl
and to make it more readable.
I'd like to ask you what you feel is critical enough to get done for a
next release. Since time is short for me, I will not be able to get
everything in that I would like. Therefore, I'd like to concentrate on
the more important stuff. The Perl 5 fix is, to me, the most
important, so that is why I did it first.
Here are some items I've received from others, but do not know if
they are important enough to get in the next release:
o text/plain filter supports Japanese character set. This
may be quick to fit in, but I'd have to look at the code.
o MacPerl support. This may take time to integrate since
the patches I've received may not encompass all the
issues about MacPerl support.
o Derived files saved in a subdirectory. This feature is
good since it helps with security concerns. However,
it will complicate message removal, which the users who
did the subdirectory feature probably did not deal with.
I would like to have the directory feature. If everything is in a
directory or single file the removal could be done with something like:
system $delete message $msgid", 'rm', '-rf', $msgid . "*";
In this case I would also suggest to strip the 'msg' in front of the
file names (saves some bits on disk and for glimpse).
Here's some other ideas that have been suggested by users, or myself:
o Threading by subject. Ugh. I personally do not want
to do this.
I really hope that someone finds the time to do this.
o Index listed last N messages, but non-listed messages still
exist in the archive, instead of being automatically
removed. Ie. The index is a window to some of the
messages. Links to previous and/or reference messages in a
message may link to messages not listed in the index.
This feature would be most useful if the index would be writen to
stdout. This enable CGI script to use this feature in a flexible
way. See also my comment on 'Multiple index support' below.
o A CGI program to allow searching of an archive. I think
this may be useful for small archives, and the program
can take advantage of the .mhonarc.db file for relational
Since it is possible to hook in separate search engines
(like Glimpse that Achim did), writing my own is usually
put low in my priority list.
o A force option. Ie. The ability for mhonarc to update
an archive, even if a lock file exists. QUESTION: Does
the locking work correctly under Windows/MS-DOS systems?
o Multiple index support. Ie. Allow users to define the
number of indexes and how the indexes are formatted beyond
what is allowed now. I like to call this the Hypermail
My Hypermail syndrome is that I would like to have the possibility
to min/max mail date in the index.
Nevertheless multiple index support has also other manifestations:
o provide a fancy and plain version of an index for
fast and slow link.
My wish would be to able to define an index by name:
(defaults are the ones used be the 'bydate' index)
Use it mhonarc like
mhonarc -index bydate,thread,myindex
So e.g. the threaded index then be 'simply' a defined by
o RFC 1522 support.
I would like to see it included.
o Automatic UUCP mail box and MH mail folder detections.
I.e. No need to specify -mbox or -mh anymore. Related
to this is the ability to process mailbox files and
mail folders (directories) with a single invocation
o Imply -add if -outdir contains an existing archive.
o Better use of memory when program is running. Ie.
Write out messages as they are processed instead of storing
all in memory before writing. This feature will require a
redesign of how mhonarc process mail, so time to implement
is unknown. Also, this way of processing is slower due to
more disk access, but can be useful to users with little
o Or item here.
Other 'I would like ...' are (from high to low priority)
o Add to the documentation/WWW home page how to add a References:
header (if possible at all with the MUA).
I suggest using mh :-). For mh I use in replcomp:
If not don't work as expected when there no References header
present. Better Solution?
o default for unknown mime types should be: include
the part as it is (for multi parts in a separate file(s)
o threaded index should be a combination of reference sort
and subject sort.
o unique file names for multi-part (a separate directory!?)
o application/pgp support
o A 'dynamic' mode: Use a mbox file to build only .mhonarc.db
Separate tools to create an index (user defined, see above)
and messages. The links would be URLs to CGI scripts that
to the conversion as requested.
This would save a lot of disk space. Indexing could still
be done with a special Harvest setup or a modified glimpseHTTP.
o Hierarchy of configuration files. I use the the same .mhonarc.rc
for all my mailing lists but would like to treat two of them
in a slightly different manner. It's boring to make the same
little changes in several rc files. Having a general and a
list specific rc files would help.
o add the current message number to the variables substituted
in the message configurations item. I have to use the HTTP
http_referer header in a CGI script to get it. This has two
- the URL is not unique for each mail
- Reloads don't supply this header
(See the [Original mail] buttons used in my mail archives)
o Specification of other .mhonarc.db files to be used for reference
links. (My archives are per month so mails at begin of a
month often refer to mail of the end of the last month.)
Also, I'd like to do a FAQ. The FAQ can be distributed with mhonarc,
sent periodically to the mailling list, and posted at the UCI mhonarc
home page. Contributions/help is welcome.
Since the major software project that I work on for my paying job is
going to start its next cycle in January, time for working on mhonarc
is running short. Please respond as soon as possible.