On May 19, 2002 at 21:54, John Belmonte wrote:
When MHonArc creates message page files it includes links to other
messages generated from the database. In contrast there is the
"-single" option for converting a lone email into HTML which doesn't
provide such links. Something in the middle of these two cases would be
useful. In other words, I'd like to dynamically generate exactly the
HTML that MHonArc normally puts into files, using only the original
email text and the database. The purpose would be to eliminate the disk
space for the HTML files. This would make sense for archives with a
large message count and/or low retrieval rate.
For on-the-fly conversion, this can be a performance issue, especially
with messages that have attachments. You have to figure out where
attachments will go and the overhead of converting them each time a
message is accessed can be very high.
I'd have to put more thought into this to really determine what
it would take to do what you propose. This idea has come up before,
and I do know it would take some work. Dealing with attachments
is a big thing.
Note, there is a feature in MHonArc that almost gets you there.
For example:
shell> mhonarc -nomsgpgs ...
Will cause MHonArc to do what it normally does, but not write out
any message pages, and more technically, skips any message body
conversion.
The idea behind this was to potentially support on-the-fly conversion,
or other message retrieval method. I.e. You use MHonArc resource
to customize the indexes to link to a CGI program (or reasonable
equivalent) that would retrieve the message.
Related to this, I noticed a long time ago that if you have the HTTP
server send a content-type of message/rfc822 for a raw mail message,
Netscape would actually render the message. Therefore, you could
use MHonArc to generate index pages (and the database), but let the
client do the actual message rendering.
As I write this message, I just checked Netscape 6, and it does
render message/rfc822 data like Netscape 4 did. It actually looks
pretty good. As for IE, it appears IE 6 will render message/rfc822
data, but it does not appear to be that good at it. You only
get to see the message body; it does not render the message header.
I do not think IE 5, and older, can render message/rfc822 data
natively.
I'm aware that the original text messages can be discarded after HTML
conversion, but throwing away the originals almost never seems like a
good idea.
You are correct. In archives I setup, I always keep the originals.
The text messages also have an advantage in that they can be
stored in a single file (mbox format as is) and picked out as needed,
saving substantial disk slack.
The main list archives for this list do this. But all the HTML
files are still created as normal.
--ewh
