[dev] Re: [cvs] commit: horde/config mime_drivers.php.dist horde/docs CHANGES horde/lib/MIME/Viewer tnef.php

[Michael M Slusarz]

Quoting Chuck Hagenbuch <chuck@horde.org>:

| Quoting Jan Schneider <jan@horde.org>:
| 
| > FYI: I have a partly completed tnef mime viewer sitting around here for
| > some month, that is completely written in php and doesn't need the 
| > external binary. Btw, the original code hasn't been written by me and
| was 
| > based on the stuff from std.com. I had never the time to finnish it and
| I 
| > didn't really had any need for it either. :-)
| 
| Maybe you can send what you have off to Michael? It'd be nice to have it 
| not require an external program.

Jan - it would be great if you could send this code to me.  I'll just 
insert it in the appropriate places in lib/MIME/Viewer/tnef.php so we don't 
need the external program.

| > Anyway, as a sidenote, I already thought about _not_ to implement it as
| a
| > mime viewer but put the code directly into lib/Message.php or where it
| > would fit best. That is because the tnef format is rather a format 
| > competing with mime/multipart than an attachment encoding. It can
| contain 
| > message text, attachments, signatures, ...
| 
| Hmmm. I'm waffling on this one. Other thoughts? I guess I really don't 
| think it should go into lib/Message.php, but it could potentially be 
| included there when necessary.... (along with a uudecode driver, maybe?).

I don't agree with putting it into lib/Message.php - I would much rather 
see it remain a MIME_Viewer.  My goal is to move _all_ code that handles a 
specific MIME Part into a MIME Viewer.  The whole purpose of a MIME Viewer, 
in my eyes, is that you should be able to pass an entire part into it and 
get back rendered text.  That is why I am going to move all 'multipart' 
handling stuff in imp/message.php to its own MIME Viewer.  All message.php 
should be doing is determining whether a part will be displayed inline or 
as an attachment - all logic concerning what exactly needs to be shown of 
each part should be handled in the MIME Viewers.

Back on subject - at this point ms-tnef is not (I believe) a viable 
substitute for MIME.  I hope that it never will be.  It makes more sense to 
fold it into the current MIME framework than try to restructure it.

just my two cents,
michael

______________________________________________
Michael Slusarz [slusarz@bigworm.colorado.edu]
The University of Colorado at Boulder