> All feedback is welcome.
Here it is :-)
- The alorithm used in the followup and refs section of a message
does not use the same (new) algorithm used as for the thread index.
Only 'true' followup & refs are used not the 'possible' ones.
Both lists should list the same messages IMHO regardless what
algorithm used.
You can now shut off the printing of the explicit followup & refs.
Hence, you can use the thread next/previous resources to provide a
direct correlation with the thread index.
- -modtime is the default. That's okay for me (thanks for the feature)
but maybe -nomodtime is a better default. Netscape cache is a real
pain when making test with -modtime :-)
Okay.
- It may be convinient to have a switch that makes the TopPNI and
BotPNI section of a message the same, e.g., to use the same 'button'
row at the top and buttom.
Not a bad idea. I have been thinking of ways to minimize the storage
use in the .mhonarc.db file. For example, it would be nice that no
information was stored for a particular resource if the default value
is being used. Providing the capability to say "Use value of this
resource" will help in storage and convienence. I'll have to think
of the resource syntax to support this feature.
- To save some bytes in .mhonarc.db one can remove the whitespace
between key value pairs (patch below). Same could be done for
%From values in .mhonarc.db, they all have
a trailing blank.
I have noticed this problem also. The %From stuff is due to the way
the message header is parsed. It should be fixed.
- require of filters on demand. Most mails I process here are not
MIME.
For a later release. It will require a restructuring of readmail.pl
to handle the responsibility of filter loading. The work may not
be that much, but I want to get higher priority stuff done first.
Also, charset filters should be handled in the same way.
- Message date: For big mailing lists I often get mail out of time
order. Suggestion: first use 'Date:' and if date convertions
fails use first date 'Received:' header.
And I have had need for the opposite. What I can do is provide an
option to determine which field has precedence, but make Date: have
the default highest precedence.
- -multipg switch: mhonarc -outdir test -multipg test.mbox
results in:
Writing mail .Illegal division by zero at /local/mail/2.0a1/lib/mhrcvars.pl l
ine 127
I thought I caught that :-(
-multipg should only be allowed if -idxsize (or corresponding env or
resource is specified)
That is the way it is now, however the division by zero is a problem.
- main/thread index button in messages always refer to indexname#msgnum
This is no longer always true if multipage is used.
Hmmm. This should not be a problem. The links should point to the
appropriate page (the demo does). If you change between single page
and multipage, you may need to use -editidx to fix things up. If
you have an example that shows the problem, please pass it along.
On a resource side $IDXFNAME$ should expand to the appropriate page
if multipage is in effect.
- -reverse and multipage links. If you add a message to such an archive
all mail*.html thrd*.html files have to be rewriten. I would not mind
if the maillist.html and thread.html would contain betwwen 1-IDXSIZE
msgs. So only these 2 files need to be updated (plus 2 other if
the total msg number requires another index file).
Hmmm, interesting idea. I'll have to see how much work that would
require.
- [First Page], [Last Page] links in multiple index pages would useful.
Good suggestion.
- Have not checked it but: Is a thread always completely included in
one thrd*.html page (even if IDXSIZE is exceeded)? Seems to be
meaningful (whatever that is :-).
Nope. Since a thread can be arbitrary in size, it is possible that
an entire archive would be stuck on a single page (losing the advantage
of multiple pages). Hence, a thread may span across multiple pages.
Thanks for the feedback.
--ewh
P.S. I have alot of stuff going on at the moment, hence, the full
release of 2.0 may be awhile. I'll try to keep the list informed
when possible.
