(I'm following-up to the mhonarc-dev list since this is appropriate
for that list. The author of the original message is being bcc'ed in
this reply. The original author is free to only correspond with me
in private if they choose to not subscribe to mhonarc-dev.)
(BTW, feature requests can be formally submitted at
On August 1, 2003 at 13:10, someone wrote:
The e-mail content typically submitted to the lists often contains simple
attachments. My users asked me to add links to the attachments to the
archive index page. I have done so and would like to see this feature
become a standard part of MHonArc so I don't have to keep adding it back in
every time I upgrade MHonArc. Though the solution I currently have is a bit
of a hack, I have a pretty good idea of how to incorporate the functionality
in a more structured way.
The purpose of my e-mail to you, is to find out if you are interested in an
enhancement like this. I am a veteran software engineering professional and
I would be willing to do the work and contribute it if you will provide
design and code review assistance. Please let me know what you think.
This type of feature has been on the TODO list for some time:
=> Provide attachment listing at top of each messages page
(suggested by Lars Aronsson). This can be tricky since filters
have ultimate control of how parts are treated, including overriding
attachment disposition. Would also require changes to how base
parsing cooperates with content filters.
It is not exactly what you are asking for, but the idea is the same
along with subsequent design and implementation.
There are two main issues with adding such a feature:
1. Preserving the existing MIMEFILTER API for backward compatibility.
2. Providing resource customization flexibility on how attachment
are listed in an index (or elsewhere). I.e. A fixed format would
not be acceptable in the standard distribution.
(1) could be addressed by allowing an alternate data structure
as the return value. For example, a return of a hash reference can
be used for the newer style of return value that explicity provides
attachment information. The mail parsing library (readmail.pl) can
examine the return value by using ref() to determine if new style
or old style return value is being used.
A slight variation is to keep the traditional list-style return
value of filters, but for each derived file listed, a hash could
be used as an alternative to a scalar string, where the hash will
contain meta-information about the file (along with denoting that
it should be considered an attachment). Right now, I am favoring
this approach verses the first, but that could change as more
Note, with enhanced attachment info, changes to the database file
format may have to be done and to insure such changes with preserve
(upward) compatibility with older archives.
(2) will require some additional resource variables to represent
attachment info: filename, description, content-type, etc. A
particular tricking part is how to handle the referencing of
multiple attachments of a single message. It will require that
a new layout resource, or resources, will be needed to facilitate
And, of course, documentation will need to be updated to reflect
all changes made :-)
I have had no real incentive in the past to add attachment listing
support, and there is some work involved (as described above).
Therefore, I have not bothered implementing it, yet. It looks like
it is definitely doable, but all bases need to be covered in order
for it to become part of the standard MHonArc distribution.
So the ultimate question is if you would like me to do the work vs you
trying to take a stab at yourself. If the latter, you should subscribe
to the mhonarc-dev list and at least get familiar with accessing the
CVS source tree, <http://savannah.nongnu.org/cvs/?group=mhonarc>.
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV