On Mar 11, 2016, at 11:01 AM, Paul Vixie <paul(_at_)redbarn(_dot_)org> wrote:
my situation is the opposite. i'd like multiple mail store types inside NMH,
or a pluggable hooks-style interface allowing the creation of same, so that i
can use NMH command line tools to attack my Maildir store as created for me
by Dovecot.
Rather than push the mailstore code into MH, I think a much cleaner model would
be to use FUSE-based providers that translate between external store formats
and the native MH layout. This means no intrusive changes to MH itself, and
people can roll whatever translators they want.
As a reference model we could include a FUSE fs that exports a Maildir
directory tree as an MH store. My guess is that's what 95% of people would
want, anyway. (And the next 4% would want IMAP.)
I have looked at the idea of implementing a simple(ish) vnode-style abstraction
layer in MH. On a high level, it's not that horribly complicated.[1] The
devil, as always, is in the details. It's really hard not descending into a
tar pit of horribleness as you start trying to support each OSes favourite
little filesystem extension. This will quickly destroy any notion of
portability in the code. Shared libraries are not that friendly to portability
efforts, either. Not without writing a lot of code that nobody here wants to
maintain over the long term.
--lyndon
[1] Long ago and far away (2000?), as an experiment, I hacked MH 6.8.4 to let
it use IMAP as a backend store. At a *very* basic level. It was much easier
than I thought it would be to get the basics working. But it quickly became
apparent that mapping the finer nuances of MH to external stores was going to
take a *lot* of thinking. And in the IMAP case specifically, MH doesn't take
well to external forces changing its world view of the message store.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers