Re: Automatic linking to a mhonarc archive

[Earl Hood <earl@earlhood.com>]

On August 9, 2002 at 12:54, Alan Burlison wrote:

> > A clarification: Are you stating that you would like to link the
> > location in the index page that lists the message with the specified
> > bug ID?
> 
> Yes, that's it.  I've tweaked the index page layout so it looks something
> like this:
> 
> 4490164: It's all badly broken 
> 	Joe.Bloggs   Mon 10 Jun 2002 07:00:26 PM UTC 
> 	Bart.Simpson  Mon 10 Jun 2002 07:50:27 PM UTC
> 4502645: And this doesn't work either 
> 	Someone.Else   Mon 10 Jun 2002 01:20:46 PM UTC 
> 	Someone.Else   Tue 11 Jun 2002 11:16:52 AM UTC 
> 
> where the first (subject) line in each block is a link target with a name
> attribute equal to the message ID of the first message in the following
> list, and the subsequent (author) lines are links to the emails in the
> archive related to a particular bugid.

In that case, the message number examples I gave you are not needed
since you are using the message-id as an anchor.

> So if I build an index where I add
> the (bugid, message id) pair the first time I encounter a given bugid, I can
> then work out the link target I need for a given bugid.  However the missing
> piece of information is the name of index file that a given link is in (I'm
> running with <MultiPg>).  I don't see any obvious way of hooking into the
> index page creation process, so my other thought was to look in the
> .mhonarc.db for the <IdxSize> and friends, and work out which index page a
> given link will be in that way.

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
   directly:

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

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 'mhamain.pl' || die qq/ERROR: Unable to require "mhamain.pl"\n/;
    mhonarc::initialize();
    if (mhonarc::process_input()) {
      # ... Your post processing code here ...
      exit(0);

    } else {
      # Some error occurred
      exit($mhonarc::CODE);
    }

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

> Yes, that's another possibility.  However, as I can guarantee that all the
> mail subjects will be of the form "<bugid> <synopsis>" I can easily group
> them together by sorting the index by subject instead of date, with
> <SubSort>, so I was just looking for some way of easily exploiting the
> well-formed nature of the mails I'm dealing with ;-)

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.

--ewh

---------------------------------------------------------------------
To sign-off this list, send email to majordomo@mhonarc.org with the
message text UNSUBSCRIBE MHONARC-USERS