Re: Thoughts on what's next.

Kent Landfield wrote:

Ok, my time to comment Kent's very extensive list of possible things to do next...

> - Support variant mail folders types. Hypermail supports only UUCP
> style mailboxes. We could create an archive of converters somewhere
> so people could grab them when they need them.

We have to re-structure the parser source code a bit to make it less intimate with the mail format in order to do that. But I guess that many of the ideas below also will call for that change anyway.

> - With the MIME model, you can extend MHonArc to handle content-types
> that it does not support by default. The granularity is better.

 If course that would be wonderful (talking as a mime content-type decoder). I'd also like to see a few other things in the mime decoding area, like proper use of <img> tags when the image of a supported format (would need configurable image formats for future browsers) is found in a mail. Today, I think most browsers grok GIF and JPEG, so there's no reason to <a href> them when they can be showed inlined...

> - Page customization. A real difference. Need to be able to give the user
> complete control on how pages are formatted, including the use of frames.

I think I'd like some kind of 'template' system instead of the current 'header' and 'footer' method. Why not have a complete 'mailtemplate' and 'indextemplate' where you have special controls code where the entire HTML-ized mail appears and certain control codes where the "next message" / "next in thread" link appears and so on?

To better support frames, I guess we'd need a way to specify which target etc to use in <a href> tags.

> - MIME support and all it implies (_real_ close but still a little to go)
>
> o Need to have the enclosure filenames tied somehow to the file it is
> linked from for removal and overwrite updates.

I have already started to plan a fix that will use the proper filename for the filename when stored as binary. I think the file should be "tied" to the proper mail file by adding a line similar to "<!--- attach=filename -->" in the generated HTML file. Wouldn't that be quite simple to do?

> o Have the MIME decoding ignore multipart/alternative and have it use
> a configured default (such as plain/text) as the primary method
> (dropping the redundant alternatives on the floor).

Indeed. It would preferable be an ordered list of what methods to prefer. (mixed/alternative types are tricky in the way that the least complex method is always presented first, so you have to parse along further down until you find the most complex method you prefer until you know what to show).

-- 
          Daniel Stenberg  -  Software, Network and Unix
    GSM: +46 - 708 - 31 77 42   http://www.fts.frontec.se/~dast