MIME-tools reviews

RSS | Module Info

MIME-tools (5.427) ***

This seems like the best dist out there for dealing with MIME messages, and I think I've used various modules from it in the past for various tasks successfully.

However, the MIME::Parser module is problematic. Its documentation is rather poor -- lots of references to 'in core' which I assume mean 'in memory', getting what I wanted (parsing a message for its headers), seemed to require me to digest several different modules' documentation.

But, my biggest complaint is that it just dumps the full body, and attachments, into a zillion files in my CWD w/o being told to. I need to tweak the poorly named 'output_to_core' setting to prevent this. Of course, I didn't notice this until after I had parsed 70000 messages...

This behavior should be more explicitly documented, at least.

Of course, I could also just be Doing It Wrong, and using the wrong tool for what I want (parsing & normalizing the headers from message text I get from another process).

MIME-tools (5.428) *****

MIME-Tools is a really great framework!

It's hard to understand it at the first look because the documentation
is too poor and it's necessary to read some code. But later you will
be pleased to spend your time on it.

I wrote my own ticket system and with MIME::Parser it was easy to
parse and store emails into a database.

Great job! My one wish: a bit more documentation :-)

MIME-tools (5.427) ****

I agree with grinder, the interface could be simpler,
and to do things like convert a message to multipart/alternative
I had to work up some dubious code, but at least it's possible
and one needn't parse messages by hand. The suite is powerful,
if not elegant, but the same could be said of any of the other
mega-modules on CPAN (LWP, DateTime, Mail::Box).

MIME-tools (5.427) ****

The module seems to work very well, although there are parts of it I don't yet understand, but the documentation is an incomprehensible mixture of annoying quips and patchy information. In the end I had to resort to reading and altering the source code to work out what the module was doing. Any documentation, for any module, needs clear pieces of sample code so that programmers can work out how to use the module. Lame quips and vague statements are not helpful.

MIME-tools (5.423) ***

You should not remove a function, but rather make it do nothing.
Removing tmp_recycling breaks SOAP::Packager as well as our customer support system RT www.bestpractical.com/rt

MIME-tools (5.418) *****

I could not begin to imagine how difficult and time-consuming it would be to deal with MIME-encoded e-mail messages without this set of modules. You can build a CGI that takes a raw SMTP message and webify it, with clickable attachement links, in about 100 lines of code (as I just did).

You do wind up writing a certain amount of make-work code, suggesting that perhaps the distribution's interface is a little too low-level, which in turn probably means you have to a certain amount of time flipping between the documentation of certain modules to get the result you want, but on the other hand, learning how it all fits together gives you a trememndous amount of flexibility.

Specific case in point, I may have been going about it the wrong way, but it took me quite a bit of effort, both in reading the documentation and writing snippets of code to figure out how to decode base64 attachements. As a minimum, I came up with

my $p = $msg->parts(1); # assuming 2nd part is the one we want
my @body;
eval {@body = @{$p->body}};
$@ and die $@;
print decode_base64(join('', @body));

To me, that seems like an awful amount of work. I'd like to be able to say something like

print $msg->parts(1)->decoded;

and it would Just Work.

The Big Five you really should take the time to study are, in order MIME::Entity, MIME::Parser, MIME::Body, MIME::Head and MIME::Decoder. A priceless tool to have in your toolbox.

(edit: typo corrected)
1 hidden unhelpful review