To Steve,
If you do not know, Achim has set up a mhonarc mailling list. Send
mail to mhonarc-request(_at_)rosat(_dot_)mpe-garching(_dot_)mpg(_dot_)de with
the single word
"subscribe" as the message.
To all,
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 Rewrote readmail.pl to work under perl 5, and added the
following:
- MIME filters can now be registered for multipart
and message types. Now, users can completely
override mhonarc's message body conversion.
- Data decoders can now be registered to decoded
encoded data; eg: base64, quoted-printable, etc.
Decoders exist be default for encodings defined
by RFC 1521, but they can be overridden if desired.
Decoder registration now allows users to hook
in a filter for non-registered encodings like
x-uuencode.
- Support for filter arguments. When a MIME filter
is invoked, an optional argument string can be
passed in to control the behavior of the filter.
The format of the argument string is determined
by the filter.
- Because of the changes, MIME filters are now
invoked as follows:
$converted_data = &function(
$header, *parsed_header_assoc_array,
*message_data, $decoded_flag,
$optional_filter_arguments);
- readmail.pl is now written so it can be reusable.
Ie. It is possible to use it as a generic
MIME processor.
- MIME filters can be registered for base types.
Example: image/*
o Fixed bug where single quotes in keys of associative
arrays in the database file were not getting escaped.
o Fixed bug where spaces were not escaped in mailto URLs.
o Fixed bug in -scan output where month in date was off by
one.
o mhonarc now will eval require statements. This way
mhonarc can cleanup properly if a require fails.
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.
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.
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.
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
queries.
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
syndrome :-)
o RFC 1522 support.
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
of mhonarc.
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
memory.
o Or item here.
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.
Thanks,
--ewh
