http://bugzilla.spamassassin.org/show_bug.cgi?id=4636
------- Additional Comments From [EMAIL PROTECTED] 2005-10-18 17:23 ------- Subject: Re: Charset normalization plugin support On Tue, Oct 18, 2005 at 02:53:29PM -0700, [EMAIL PROTECTED] wrote: > > Potentially, there'd be a new function in Message like > > "clear_rendered_cache" or something which would delete the cached forms > > of text_rendered, text_visible_rendered, text_invisible_rendered, and > > (if necessary/different function) text_decoded. > > If the cache got filled before the normalization plugin got invoked, that > would > indicate a bug in the order of execution. Not really. What if I have another plugin that gets called at the same time or earlier because it wants to do something, whereby it populates the cache? > There's no clean OO separation between data and view, but that was > preexisting--Message::Node already knows almost everything about > SpamAssassin's > view of MIME entities. I'm not sure I follow here. Message and Message::Node are wholly separate from the rest of the code, with the exception of a handful of calls into Util. What does the SA code know about the message that doesn't come from Message or Message::Node, which then those hook into? > I was thinking that having a plugin allowed people more flexibility in tuning > the normalization process, but perhaps that's not strictly necessary. I would imagine that there wouldn't be a lot of overhead if there's not a lot of normalization going on. If incoming messages aren't in any special charset, I would assume a negligable time penalty to processing. As I recall, we added the "use bytes" stuff everywhere because there were large performance issues with RE against Unicode data, but that was almost three years ago so the details escape me. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
