Re: Automatic linking to a mhonarc archive

2002-08-09 15:08:27
Earl Hood wrote:

The location of a message on an index page is not known until MHonArc
is writing/editing the HTML pages.  A solution would require two
step process:

1. Use the $mhonarc::CBMessageHeadRead callback to store the index
   and message-id of new messages (probably in some kind of hash).

2. At the end of archive processing, go through your hash and
   resolve which index page each new message is listed under.  This
   could be done by calling the mhonarc::replace_li_var() function

    $idx_file = mhonarc::replace_li_var('$IDXFNAME$', $index);

   Where $index is the message index you save in
   $mhonarc::CBMessageHeadRead.  Now you should have the
   index filename and the message-id (which you grabbed in
   $mhonarc::CBMessageHeadRead) to support your linking.

Excellent - that sounds like exactly what I want.

Step (2) would require you write your own front-end to MHonArc so
you can do step (2) after an archive has been processed.  Example:

    require '' || die qq/ERROR: Unable to require ""\n/;
    if (mhonarc::process_input()) {
      # ... Your post processing code here ...

    } else {
      # Some error occurred

The alternative is to put your stuff in the $mhonarc::CBDbSave callback
since the database file is written after all pages have been written.

I was intending to write my own front-end ayway, as I will probably drive
this processing directly from a '|' entry in /etc/aliases.

Note, it is technically possibly for a message's listing on an index
page to move to another page when MULTIPG is active.  This can happen
if an older message happens to be passed into mhonarc before a newer
message.  Also, the probability of message listing moving increases if
REVERSE is active since newer messages will be listed *before* older
messages.  This could cause an older message listing to be "pushed"
to the next index page when new messages are processed.

Therefore, to be extra careful, you may have to traverse all messages
in the archive each time during archive updates instead of just
handling new messages.

Ecch, I hadn't thought of that.  I'm not using REVERSE, so the problem
shouldn't be so severe, but thanks for the tip anyway.

Something else I have done is to tweak the text/plain filter so that rather
than quoting messages by surrounding them in <i>...</i> tags, it uses <span
class="quote">...</span>, so I can turn them a purty color using a
stylesheet.  I've finished hacking my 400-line .mrc file, and it all looks
*very* pretty - now for the final programmatic glue :-)

Once again, thanks for all your help.  Once I have this all working, I'll
send in the bits if anyone is interested!

Alan Burlison
$ head -1 /dev/bollocks
interactively synthesize seamless extensible portals

To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the