> 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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
