> 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.)
It would be nice, but I do not think it is a major issue.
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 . "*";
First, the system call is useless on non-Unix systems. I'd I
have to write my own directory removal routine.
As a quick solution, I plan to have filenames mentioned in the message
ignored by default for the purposes of the actual filename used for a
derived file. This will avoid filename conflicts and security problems.
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).
Could have problems with backward capatibility. This issue is not
critical.
> 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.
Do something that works intelligently will take some time. I currently
do not have the time for it.
> 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.
I've had this on my todo list for awhile. Forgot to mention it.
> 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 :-)
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:
<IDXHEAD MYINDEX>
[snip]
I've thought of somthing similiar, but it will take time to
implement it. It will probably require some major recoding, and
I'm not ready to do that.
>
> o RFC 1522 support.
I would like to see it included.
Me too.
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:
...
%<{message-id}References: \
%<{references}%(void{references})%(trim)%(putstr) %>
%(void{message-id})%(trim)%(putstr)\n%>\
A reasonable request.
o default for unknown mime types should be: include
the part as it is (for multi parts in a separate file(s)
known000xyz.txt)
This is tricky, especially for multipart/alternative. It can be
done, but some additional logic and modification must be made to
make things work according to rfc 1521.
o threaded index should be a combination of reference sort
and subject sort.
Yes. Subject sort allows some form of grouping of messages that
fail to include references.
o unique file names for multi-part (a separate directory!?)
See comment above.
o application/pgp support
Any body can write this. All mime filtering is independent of
the processing code.
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.
Yes this would be nice, but time is an issue.
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.
I've contiplated in the past of having a system rc file that is
installed during installation. Then the administrator could edit
it as desired. It would work as global defaults, while local rc
files can override it.
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
disadvantages
- 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.)
This can complicate things. The way things are coded, this will not
be trivial to implement. I like the idea, but it will take time
to do it.
A big issue with feature requests is keeping compatibility with older
archives. Ie. A user would not have to regenerate archives each time
a new version of mhonarc comes out. Some features requested will make
backwards compatibility very difficult.
Also, time is a big factor. Since mhonarc is developed on my spare
time, big changes are harder to do. I try my best to get in as much
as I can.
--ewh
