[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] What are and what should be the qualifications for a c

From: Lyndon Nerenberg
Subject: Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user
Date: Mon, 17 Nov 2014 14:19:44 -0800

On Nov 17, 2014, at 1:38 PM, Paul Vixie <address@hidden> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

reply via email to

[Prev in Thread] Current Thread [Next in Thread]