Re: [Nmh-workers] nmh @ gsoc?

[Lyndon Nerenberg]

> know about you, but when I go to look at a software package and I see
> the last new release was 5 years ago, my first thought isn't, "Oh, it's
> perfect!  That's why they stopped developing it!"; it's "Oh, I guess
> that project is dead".

I know. It's referred to as "Slashdot syndrome."

On an daily basis I'm using large swathes of code that haven't been 
touched in years, or even a decade. They stopped developing it because it 
works. Even five or ten years later. But today everybody wants to be a 
'cool open software developer' which leads to insanity like Linux's 
cat(1). (I'm not accusing anyone here of being that way; my point is 
that's become a general malaise in today's software community.)

> - TLS support

That one I'll give you.

> - IMAP support (I am not interested in arguing about whether or not this is
>  a good idea, "breaks the MH model", or other such nonsense - the
>  undeniable truth is that there are people who are interested in it).

I have wrestled with this one for years. By adding a VOP-like interface to 
the message store you could have two storage backends -- the native file 
store, and IMAP. But the pile-on will start immediately, and in no time 
we're dragging around 15 different storage backends, each with their own 
little quirks that need little tweaks to various MH commands, leading to 
the inevitable mess of conditional code, and the complete loss of the 
elegance and symmetry of what's there now.

IMAP support is better handled completely outside of MH. With the advent 
of FUSE, the way to do this is to build an IMAP client that exports an 
MH-style file tree via FUSE. Then all you need to do is 'export 
MAILDROP=/mnt/imapfs' and everything just works. (Absent FUSE you can 
use loopback NFS mounts.)

> - Some sort of embeddedable language support for components files

I'd rather see hooks in the component files that make it easy to invoke 
external commands. It's much more in spirit of the "scriptability" of MH. 
Execing things has higher overhead than an embedded language, but I doubt 
it would really be that noticeable. And I would certainly trade off the 
overhead of the exec() vs. the overhead of the additional code complexity 
that comes with embedded languages. And there would be more than one -- 
just like multiple message stores, if you open the door the flood *will* 
commence.

--lyndon