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
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers