On May 20, 2002 at 02:06, John Belmonte wrote:
Right, I'm suggesting in this scheme that HTML messages never exist in
file form. MHonArc would generate indexes and the database as it does
now, but message HTML would be generated on the fly.
What to do with attachments????
Grabbing input text messages seems like it should be outside the scope
of MHonArc, as they may be individual files, a single mbox file, a
compressed mbox, in a custom database, etc.
Agreed. MHonArc does have some signs of its age. Note, MHonArc can
read from mbox data from standard in, hence, almost anything can be
used to pipe data into MHonArc. Under Unix, you could also use FIFOs
if standard input is not a convenient option.
Ideally, there would be an abstract interface that defines the
operations of a mail input stream. Then there would be multiple
implementations represented the various type of possible input, with
pre-existing common ones for UUCP-style mailbox files, MH-style
mail folders, etc.
It would be necessary to associate MHonArc message numbers with your
text messages. One way to do this is make a new way to update MHonArc.
Messages would be fed one at a time and MHonArc would return with the
(possible already existing) message number. Later when you want the
HTML for a message you give MHonArc the message text and the message number.
You can also use message-IDs since MHonArc does store message-IDs.
The problem is doable. The trickiest part would be how to deal
with attachments. This will impact the content/MIME filters.
--ewh
