MIME_Viewer

[Anil Madhavapeddy]

Just wanted to elaborate on the MIME_Viewer commit.  Its purpose is to
be able to flexibly use stuff like Enscript, Wordview, etc among all the
Horde applications (notable IMP, Chora and Gollem which could really use
this functionality).

First of all, this doesn't yet replace the existing mime.php stuff.
Hence the clunky mime_mapping.php and mime_drivers.php configuration
files.  I didn't want to get too deep into it without letting everyone
else see the work though, so I want to make sure the basic design is
sound before committing 100 output drivers :-)  Once it is finalized, we
can integrate with the existing code.

The basic problem was that in a MIME context, file extensions don't make
sense.  So the first thing I did was to grab as many known file
extensions as possible from Apache, and convert them into a starting
configuration file.  The reason I didn't use mime.types as-is is that it
contains a lot of redundant information.  There's a simple perl script I
committed that we can use to sync with Apache if we need to.  Secondly,
if we can't recognise the file extension as a valid file type (for
example, C or perl files with a .pl extension), then it gets mapped to
x-extension/<extension>.  From this point on, it can be handled as any
other MIME type.

All this is handled by the MIME_Magic class.  In the future, it should
be extended to use the registry to figure out if the current application
wants any specific overrides.  So, for example, Turba could handle
VCards differently from Chora.  Also, it could use mod_mime_magic, if
available, and so forth.

Now we have some content, and a MIME type, encapsulated in a MIME_Part
object.

Each output driver registers itself as being able to handle a given set
of MIME types (the php driver only handles .php[3s] files for example).
The MIME_Viewer is a factory class which figures out which driver to
use, from the mime_drivers.php configuration file.  If multiple drivers
can handle a given MIME type, then the user can choose which one to use
in the overrides section.  This is all done from the mime_drivers.php
config file.

So, this what the HTML output drivers do is output a fragment of HTML
which the application can do whatever it wants with.  Chora currently
just sticks its toolbar on top and renders it.  IMP could display this
inline or in a separate window, as desired, etc.

So, what do you think?  This is a first pass, so get the criticisms in
now :-)

Misc thoughts:

- I'd like to let the user map actual filenames to an output driver.
Enscript can pretty-print ChangeLog files for example, which isn't
covered by the current framework.
- Need to think on exactly how the MIME_Magic / registry interaction
would work.

Anil

PS: There seems to be an infuriating bug in IE.  Even if I set the
Content-Type to text/plain, it interprets the extension of the file and
ignores the Content-Type.  So, pretty printing .xml files doesnt work
unless Chora munges the extension to be .xml_ (or something else).  Any
workarounds for this?