[Top][All Lists]

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

Re: [Nmh-workers] nmh @ gsoc?

From: Lyndon Nerenberg
Subject: Re: [Nmh-workers] nmh @ gsoc?
Date: Mon, 25 Jan 2010 13:00:21 -0700 (MST)
User-agent: Alpine 2.00 (BSF 1167 2008-08-23)

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.


reply via email to

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