Matt Sergeant wrote: MS> Craig R Hughes wrote: MS> > Yes, see bugzilla #18 which I merged into #130. This is the major piece of MS> > stuff I'd like to get done for 2.30 -- and I'm actually quite motivated to do MS> > the coding myself; I have a couple of other things I'm probably going to be MS> > working on, but might well have 130 done by month end. MS> MS> I'm thinking of doing this this week, so let me know if you want me to MS> hold off.
No, by all means, go ahead. I was steeling myself up for it, but wasn't on the verge of actually swallowing hard to get it done. I'm assuming you're talking about both 18 and 130 combined. MS> I've also got some mail parsing code you may be interested in rather MS> than using MIME-tools, or whatever the plan was. It's pretty sweet code MS> based on some stuff I wrote a couple of years ago now. I've been running MS> it over some large archives and it does pretty well. I thought it might MS> be better as it reduces dependencies a bit, however it does require MS> MIME::Base64, MIME::QuotedPrint, File::Temp and Text::Iconv (to MS> down-convert everything to UTF-8). One bonus of it is that it never uses MS> RAM for decoding - it always uses temp files (which is very fast on MS> Linux). Unfortunately I don't have a great deal of time to incorporate MS> it, since we've already got our own custom mail parsing code in house here. I'd say it's a judegement call. I like MIME::Tools (well MIME::*) because: 1. It seems functionally complete in terms of what we need 2. It's the "straightforward" way of doing MIME in perl 3. Lots of other users, so we get the million eyeball benefits In favor of non-MIME::* solution: 1. If you're going to be implementing it, and you're more comfortable with the other stuff... 2. MIME::* is probably more generic, and therefore possibly less performant, or less tailored generally for the exact thing we're wanting to do I don't think the RAM vs temp file is necessarily all that compelling, for one because we're not talking about cranking huge files with giant multi-meg attachments -- these will be size-limited MIME files. Secondly, it'll probably cause more portability issues. Without looking at the code at all, I'd be willing to bet that while linux performance is probably great, it'll be really nasty on Windows, if it indeed works at all w/out modifications. Whadya think? C _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
