On Wed, 2004-02-18 at 22:26, David Muir Sharnoff wrote:
> For all of the decoded text, I suggest "alltext". I don't like
> "decoded" as the main distinction from "body" or "text" is that it
> includes more parts. I especially don't like "rawdecoded" as there
> is nothing raw about it.
The reasoning I had behind 'Rawdecoded' was that it would make sense if
the part was exactly the same as Raw (current Full), with the exception
that all parts and headers that needed be were decoded. Currently, the
'rawbody' is not that way.
> Oh, and I have a suggestion for an addition one: "html" for decoded
> html portions.
I think this is a very good idea. The same text that is removed from the
current 'Body' part would make the the 'HTML' part.
This would create the possibility of removing a large number of 'eval' rules
(IMHO, the less 'eval' type rules the better, because rule writers typically
aren't going to write eval rules).
Let's just take one for example, FORM_ACTION_MAILTO.
Currently, this is:
body HTML_FORMACTION_MAILTO eval:html_test('form_action_mailto')
With an 'HTML' part, this could be:
html HTML_FORMACTION_MAILTO
/<\s{0,5}form[^>]*action\s{0,5}=\s{0,5}('|")?\s{0,5}mailto:/i
As far as I can see, all of the 'html_test' evals could be written in rule form
like this, if there were a 'HTML' part. (Though, I suppose you could still
write them in rule form, against the current Rawbody, but a HTML part would be
more efficient).
I would also point out that while this rule is currently listed as a 'body'
rule, it really isn't (hence the possible need for a 'eval' part).
Just to re-iterate what has already been said, but in this more descriptive
thread:
1. The current message parts names aren't descriptive, new terms may possibly
be a good idea.
2. New parts may also be a good idea. A virtual 'Eval' part (As the parts
assigned to eval-type rules, as is, don't necessarily have any bearing on where
the rule is applied), and a 'HTML' part containing all the HTML from the
message.
