I have no religious objection to a native IMAP
implementation; I would actually like that to happen.
In a general sense it is worth investigating whether MH can be
extended to use more than the traditional message store, without
breaking its long-standing semantics. I have spent a lot of time
trying to understand what multistore semantics might mean. IMAP maps
quite naturally to the native MH store, and MH itself naturally fits
the IMAP offline client model. Could this be extended to encompass
more alien message stores, such as Exchange? I don't know. But I do
think MH is a viable platform for researching new mail access models.
It's modular, it's scriptable, and it's still relatively platform
agnostic.
What's needed is a VFS-like API that abstracts the message store from
the rest of the code. This isn't hard to do. At Messaging Direct I
wrote a couple of implementations based on our first IMAP server,
which was based on the CMU Cyrus code, which itself used the MH
message store format as the basis for its message store. The API was
pretty straight forward, and easily accommodated a wide range of
backend message stores (from raw block storage devices to synthetic
web based abominations). In hindsight now I would change it a bit,
but it's still a simple interface. Gluing this in would give a
platform that would admit a wide range of storage systems, networked
or otherwise.
If people are truly interested in exploring this approach I'm willing
to commit some time to the design and coding (modulo paying the rent).
Note that I don't think MH can or should be mutated into something
that will deal with every half- or quarter-baked messaging system the
Web 2.x crowd dreams up; I don't do bling, so if that's what you want,
bugger off :-)
--lyndon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers