But wait I just realized that I jumpedto fast into an implementation
issue. What I would really like to have is
o ARI (Archive Msg Identifier)
o extention to mhonarc to use the $w3archive/$ARI instead of
$w3archive/my-substruct/{msg*.html,ext*.ext}
o ARI -> filename translation table
With this I can serve the archive via a CGI script that does
$file = pathinfo2ARI;
print HTMLheaderfor($file)
print `cat $file`;
This would be a wonderful feature... It's something that I had forgotten
about, but ran into a while back. It would be especially useful if the
ARI could be chosen by the user -- that way filenames could actually match
a header from within a mail message (Message-Id:, X-NCSA-md5:, etc.)
In my search engine at
http://www.mallorn.com/lists/perennials/search.cgi
I ended up having to do a lot of hacks to get things to work. My messages
come in via procmail and are archived, then go to MHonArc. Since there's
no easy tie between the MHonArc generated pages and my original messages,
I have to use glimpse on the MHonArc-generated HTML pages. Of course, I
don't want to match all of the extra comments and stuff at the top of the
HTML, so I have another script that runs nightly to 'textify' the messages,
but still keep a similar filename. I then run glimpse against the
'textified' messages that I converted from the original HTML messages.
So when someone does a search, it looks in the converted HTML messages for
a match. If it finds one, it then uses that filename, strips off the path,
and looks in the real MHonArc directory for a filename that matches. Once
found, it displays it.
If I could have a filename to header mapping, I could use glimpse on the
actual incoming mailbox instead without having to do my funky conversion.
That would save me disk space, time, and remove another potential
breaking point.
Chris
