Re: Preferring text/plain over text/html?
On February 6, 2002 at 23:18, Mike Acar wrote: > > > Is there a way to get MHonArc to prefer text/plain versions of messages > > > over text/html in multipart/alternative? > > > > Not without code changes. > > > > Currently, if you specify that text/html should be excluded, then the > > text/plain will be used, but the exclusion applies to all text/html > > data, even for non-multipart/alternative messages. > > Which would be ok with me; I can't really see that there's any reason to > send HTML to this list. Then you can use the MIMEEXCS resource. > > Some thought needs to be applied on what would be the best way to > > support such a feature. One part is that actual implementation, the > > other is how the user would tell MHonArc about multipart/alternative > > preference ordering. > > Well, by far the most common is text/plain and text/html sent by such > clients as Outhouse (which you love so well ;), so the obvious thing > would be simply adding a prefer-multipart-plain-over-html config option. This is too specific. There can be other cases where you may want to set a preference list of types for multipart/alternative data. > More generally I guess you could have a config section that specified > a a multipart type and a list of MIME types in order of preference... A > truly generic solution might be difficult to describe elegantly in a > config file. Exactly. Maybe something like: text/enriched text/plain application/pdf text/html The list goes from most prefered to least prefered. A problem is how mhonarc should order things for a multipart/alternative message that includes some parts that are in the list and some that are not. What to do about the ones not in the list. An alternative approach is to specify paired preferences settings. For example: text/enriched; text/plain text/plain; text/html This states that text/enriched is prefered over text/plain and text/plain is prefered over text/html. I.e. If a message contained a text/plain part and a text/html part, the text/html part will automatically be discarded since the prefered text/plain part exists. Of course, mhonarc should be smart enough to resolve the case where a message contained a text/plain, a text/enriched, and a text/html part: text/enriched should be the winner. You also have other types of complexities: text/plain; text/html text/enriched; text/html The winner would then be determined by the part ordering in the message. If text/enriched occur later than text/plain, text/enriched wins. Otherwise, text/plain wins. Now, the issue with unspecified types is handled pretty easily (and come to thing about it, the approach I am going to mention could apply to the first usage of MIMEAlternativePrefs). MIMEAlternativePrefs basically defines a exclusion list that only applies with mulitpart/alternative data. For example, a text/html part is automatically excluded if a text/plain part exists. Once all parts are excluded, the part ordering sematics of mulitpart/alternative come in to determine which part wins out. With this model, the first MIMEAlternativePrefs usage (specifying a preferences list) can be used and should be less confusing than the second usage. A subtle problem that could show up is the case of nested multipart/alternatives. For example: --XXX Content-Type: text/plain asdfasd --XXX Content-Type: multipart/alternative; boundary="YYY" --YYY Content-Type: text/html ... --YYY-- --XXX-- In this case, the text/html would sneak through. Now, if the MIMEAlternativePrefs is implemented a certain way, the above could be addressed with the following setting: text/plain text/html multipart/alternative This states that a text/plain or a text/html has precedence over a nested multipart/alternative part. It would be cool if multipart/alternative nesting was "flattened" out, but I think this would take too much work, and since it is probably extremely rare to have multipart/alternative parts within multipart/alternative parts, why bother. The final thing to deterime if base types should be supported. Example: text/* image/* --ewh
Re: Preferring text/plain over text/html?
On Wed, 06 Feb 2002 09:36:54 -0800 Earl Hood <[EMAIL PROTECTED]> wrote: > Some thought needs to be applied on what would be the best way to > support such a feature. One part is that actual implementation, > the other is how the user would tell MHonArc about > multipart/alternative preference ordering. FWIW this is what exmh does (my preferred MUA) and it works very nicely. -- J C Lawrence -(*)Satan, oscillate my metallic sonatas. [EMAIL PROTECTED] He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
Re: Preferring text/plain over text/html?
Earl Hood <[EMAIL PROTECTED]> wrote: > On February 6, 2002 at 16:02, Mike Acar wrote: > > > Is there a way to get MHonArc to prefer text/plain versions of messages > > over text/html in multipart/alternative? > > Not without code changes. > > Currently, if you specify that text/html should be excluded, then the > text/plain will be used, but the exclusion applies to all text/html > data, even for non-multipart/alternative messages. Which would be ok with me; I can't really see that there's any reason to send HTML to this list. > Some thought needs to be applied on what would be the best way to > support such a feature. One part is that actual implementation, the > other is how the user would tell MHonArc about multipart/alternative > preference ordering. Well, by far the most common is text/plain and text/html sent by such clients as Outhouse (which you love so well ;), so the obvious thing would be simply adding a prefer-multipart-plain-over-html config option. More generally I guess you could have a config section that specified a a multipart type and a list of MIME types in order of preference... A truly generic solution might be difficult to describe elegantly in a config file. -- Brilliance and gorgeousness| Mike Acar And we tell ourselves we don't want the treasures | [EMAIL PROTECTED] But we hate the glass anyway |
Re: Archive One Message Behind Using -add
On February 5, 2002 at 10:19, Don wrote:
> I'm attemting to keep an archive automatically up to date using
> a .forward file. When I use the -add option, the archive is always
> one e-mail behind. ie, If the mail box has 4 messages, only 3 will
> display on MHonArc. When message #5 comes in, MHonArc will display
> 4 messages. If I remove the -add option, which has the effect of
> rebuilding the entire archive, the archive is kept up to date. This
> works for now, but as archives get very large this would of course be
> problematic. Any Ideas?
My initial hunch tells me it may have to do with the mechanics on how
sendmail is invoking things. Does sendmail invoke each forward
component in sequence (and if so, what is the order), or in parallel?
If there is some parallelization, there could be race conditions
between when sendmail appends beta's spool file to when mhonarc (via
webnewmail) reads the spool file.
If sequence, it is possible that sendmail calls "|./webnewmail"
first before appending to beta's spool file.
You could easily do some tests to find out what is going on by
replacing webnewmail with a simple program (like cat) that just
dumps the contents /var/mail/beta to some temp file. Then
you can examine the temp file to see if the new message actually
exists or not.
> .forward file: \beta, "|./webnewmail"
>
> Snippet of ./webnewmail:
> @ARGV = ("-quiet",
> "-rcfile",
> "$MRC/date_p_beta.mrc",
> "-rcfile",
> "$MRC/indice.mrc",
> "-title",
> "Project Beta Date Index (by reverse date)",
> "-ttitle",
> "Project Beta Thread Index (by reverse date)",
> "-sort",
> "-reverse",
> "-treverse",
> "/var/mail/beta",
> "-outdir",
> "/export/home/beta",
> "/var/mail/beta");
With what you have, using webnemail in the .forward is useless. I.e.
The .forward file tells sendmail to pipe a copy of the message to
webnewmail, but the @ARGV settings is telling mhonarc to read from the
spool area. I.e. Standard input of webnemail (which contains a copy
of the new message) is being ignored. Hence, you are relying on
sendmail to append the new message to /var/mail/beta before
webnewmail is called.
With what you have, it is probably better to use a cron job, which I
generally advocate. With cron, you can managing load better and deal
with problems better.
--ewh
Re: Preferring text/plain over text/html?
On February 6, 2002 at 16:02, Mike Acar wrote: > Is there a way to get MHonArc to prefer text/plain versions of messages > over text/html in multipart/alternative? Not without code changes. Currently, if you specify that text/html should be excluded, then the text/plain will be used, but the exclusion applies to all text/html data, even for non-multipart/alternative messages. Some thought needs to be applied on what would be the best way to support such a feature. One part is that actual implementation, the other is how the user would tell MHonArc about multipart/alternative preference ordering. --ewh
Preferring text/plain over text/html?
Is there a way to get MHonArc to prefer text/plain versions of messages over text/html in multipart/alternative? -- Brilliance and gorgeousness| Mike Acar And we tell ourselves we don't want the treasures | [EMAIL PROTECTED] But we hate the glass anyway |
