Re: [Nmh-workers] A useless but interesting exercise: Design MH from scratch in the 2014 context

[Jon Steinhart]

So again, I think that the UI issues and message store issues are independent.
I'm personally much more interested in the UI issues.  As I've said before,
the ability to scan/next/prev/show attachments would do it for me.  This
wouldn't be too hard to add to the current UI.  Oh, and the ability to
show an attachment to stdout.  I'd work on it if I had time.

I don't want to mess with the message store because of the number of tools
that people have written that count on that format.  And, I don't think that
it needs to be changed.  Many years ago I added the hooks interface to nmh.
Hasn't been as controversial as my attachment handling stuff, which makes me
think that it isn't widely used.  The hooks interface allows you to specify
programs in your profile that get invoked when messages are 
added/deleted/refiled.

I use these hooks to build a separate searchable database.  I have a number
of additional command line utilities that operate on this database.

Any of you could use these hooks to maintain a separate directory tree that
stores mail in a format that you prefer, such as one directory per message.
And, I suppose, you could construct scripts that would pluck attachments from
that tree.  You could use the hooks to prototype your ideas for other storage
formats.  Probably less than an hour of work.

I would point out that a minor problem with this approach, which would also
exist if nmh were to change storage systems, is making sure that the subsidiary
files are synchronized with the originals.  I have (and nmh would need) a
fsck-like utility that checks and fixes this stuff.  Problems don't often arise,
but a disk-full or system crash at the wrong time can mess things up.

Jon