Re: [Nmh-workers] Future directions for nmh

[Lyndon Nerenberg]

> On Mar 11, 2016, at 11:01 AM, Paul Vixie <address@hidden> 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.