mhonarc-users

Re: mhonarc next release

1996-01-03 15:24:31
Ooops,

I forgot some topics in my last mail. First the things that I
consider as a misfeatures/buglets in the current version:

    1) message date and received header: As you could in this message
       Digital Unix sendmail places the date into
       (split(';',$received))[2] and not into 
       (split(';',$received))[1] as expected by mhonarc. My brute
       force patch appended below loops over the splice [1...2]
       to get the date. This patch fixes also the problem that
       if no date could be found in the received header then the date
       header is scanned. The current version assumes that the date
       could always be found/identified if received header is present.

    2) The 'From ' header on an mbox is not an true header, it's
       the envelope address. I think mhonarc should ignore it
       or convert it into the 'Return-Path:' header as mh does
       (mhs compile option RPATH). In this case mbox and mh mails
       would be the same.

    3) The default for the end of the thread index and bydate index
       are different. bydate gets

      <HR>
      <ADDRESS>
      Mail converted by <A
      HREF="http://www.oac.uci.edu/indiv/ehood/mhonarc.html";>
      <CODE>MHonArc</CODE></A> 1.1.0
      </ADDRESS>

       appended at the end. I think the defaults should be the same.
       (I fixed this with a <TFOOT> ... </TFOOT> definition in .mhonarc.rc)


Second my updated 'I would like to have' list.

Achim Bohnet said:
Earl Hood said:
 [...]
 [...]
 > 
 >   o  Or item here.

Other 'I would like ...' are (from high to low priority)


        o Some time ago you send me a stricter version of $FROM
          for mbox files. Could you make this the default? It
          would save a lot of time for people with wrong configured
          tools that don't escape the 'From ' in message bodies.

        o Add an -listname option. This is useful for the index
          titles and URL 'button':

          mhonarc -listname FooBar

          gives the (new default?) title: FooBar Mail Index
                                          FooBar Mail Thread Index

          and button: [FooBar Index] and [FooBar Thread]

       o An option that allows that <LISTEND> <TFOOT> are only
         displayed if more that a given number of messages are
         in the archive. Mabe another index element name would
         be better. See the (modified) mhonarc archive as an
         example where an button row at the end of the list is
         not useful because there are to less messages.

       o Message customization: it would be nice if the buttons before
         the subject are full customizable as the footer and head of
         a message. 

         An even better solution IMHO
         would be change the default of <(T)MSGHEAD> to be the same at
         button row before the subject. I don't like the have two buttons
         rows. I currently achive this with the dirty trick:

<TINDEXBL>
[Thread]</A><A HREF="../">[Top, Search]</A><A HREF="../../">[Archived 
Lists]</A><A HREF="/mailing
-lists/cgi-bin/extractmbox">[Original Mail]
</TINDEXBL>

     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?

       Yeah :-). This handles a missing References: header better:

...
%<{message-id}References: \
%<{references}%(void{references})%(trim)%(putstr)\n            %>\
...

       Want is still missing: If no References: header is present
       try to extract the message id for the In-Reply-To: header.
       A fix would be welcome :-)

        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 Possibility that error messages are send as email when mhonarc
      is used with a .forward file

    o X-face: header and PIcons (formerly faces database) 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 Possibility that error messages are send as email when mhonarc
      is used with a .forward file

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

           o Don't use the main package for mhonarc. Start mhonarc
             with (or something like that)

                #!/usr/local/bin/perl
                package mhonarc;

             This is basic requirement to patch mhonarc to be used as a
             standalone script or a library call. (It's useful because
             I call mhonarc from other perl scripts several times).

 [...]
 > 
 > Thanks,
 > 
 >   --ewh

So long,
Achim


Thanks for making me thinking about mhonarc. During writing I fixed
several things that were on my Todo list for a long time.

Btw. let me know what of my list you don't like
to see implemented. It may be the case that I find
by accident some free time lying around to work on
the one of the above topics.

Achim

--- MHonArc1.1/mhonarc     Wed May  3 21:27:57 1995
+++ MHonARC1.1+/mhonarc  Thu Dec 14 22:23:48 1995
@@ -956,8 +956,20 @@
     if ($fields{'received'}) {
        @array = split(/$'X/o, $fields{'received'});
        $tmp = shift @array;
-       $date = (split(/;/, $tmp, 3))[1];
-    } elsif ($fields{'date'}) {
+       foreach $test ( (split(/;/, $tmp, 3))[1..2] ) {
+           $_ = $test;
+           s/^\s*//;
+           s/\s*$//;
+print "\n?";
+           if (/(^Mon)|(^Tue)|(^Wed)|(^Thu)|(^Fri)|(^Sat)|(^Son)/ ) {
+               $date = $_;
+               last;
+           }
+        }
+    }
+print "!" if $date ne '';
+    
+    if (($date ne '') && $fields{'date'}) {
        @array = split(/$'X/o, $fields{'date'});
        $date = shift @array;
     }
@@ -1056,7 +1068,7 @@
     local($ret, $data, @files);
 
     while (<$handle>) {
-       last  if $MBOX && /$FROM/o;
+       last  if $MBOX && !$ADDSINGLE && /$FROM/o;
        $data .= $_;
     }
     return ''  if $skip;


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