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
