On Nov 17, 2014, at 1:38 PM, Paul Vixie <paul(_at_)redbarn(_dot_)org> wrote:
well, it does. with mime and calendaring and push, email is not a lonely application any more. to the extent that MH can't play in that world, it loses relevance. (i was an MH hardliner for 22 years, but these days i only use MH when searching my older archives, and this is the reason.) if we'd like MH to become relevant and remain relevant, it has to become a reasonable bearer channel for the apps that our families without shells or terminals can use to exchange data with us.
And that means it needs to become a very efficient and flexible dispatcher (and inhaler) of MIME content. I'm going to keep harping on about Plan 9, but the plumber[1] is a very good example of one way to abstract the specifics of content from the applications that are passing that content through. Acme, as an editor, has no knowledge of anything other than files containing newline delimited lines of text. But when combined with the plumber, it can display Postscript and PDF documents, compile C programs, offer up ical invites, ... even provide a relaxing session with eliza after a long hard day displaying nmh mailing list traffic. Building in anything more than text display and input breaks the fundamental contract upon which MH was built: Text comes in, text goes out. What modern MH is missing is a powerful enough interface to allow MH users to devour that MIME content in a useful manner. That means a much more powerful API between MH's internal MIME processing and the outside world. Plan 9's upasfs has shown one way, but that won't work for UNIX. But I do think there are ideas to be taken from Plan 9's plumbing interface; the content dispatch model is very powerful. We do that to an extent now, with some very tortured config file directives. Breaking the MIME content dispatch out and giving it its own configuration language would make this a lot easier. The primary motivation for creating the 'lmh' development branch was to bring lua into the content dispatch arena. All summer and fall we have been moaning about how we can't get the fine-grained control over the content display we need. And the recent ical conversation nails the spike into any idea of a generic solution. It's not the plumber, but it might be one way out. As this week's conversation shows, static dispatch for things like ical objects just doesn't – always – work. Sometimes it can, sometimes not. The failing the current nmh-vs-ical debate points out is that nmh can't dispatch based on dynamic MIME content. The lmh branch of the code is trying to play with this ... [1] http://plan9.bell-labs.com/sys/doc/plumb.pdf
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Nmh-workers mailing list Nmh-workers(_at_)nongnu(_dot_)org https://lists.nongnu.org/mailman/listinfo/nmh-workers