> On Mar 11, 2016, at 11:01 AM, Paul Vixie <[email protected]> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
