mhonarc-users

Re: mhonarc next release

1996-01-02 18:17:40
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
        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 :-)

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>
...
<IDXHEAD>

<IDXLISTBEGIN MYINDEX>
...
...
</IDXLISTBEGIN>

<IDXSORT MYINDEX>
myindex.pl:idx'myindex'sort:myindex.html
</IDXSORT>

(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

<IDXSORT MYINDEX>
thread.pl:idx'thread'sort:threads.html
</IDXSORT>



     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
        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.

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%>\
...

          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)
          known000xyz.txt)

        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
          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.)

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

So long,
Achim



<Prev in Thread] Current Thread [Next in Thread>