> 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 didn't explain this properly. By "multistore semantics" I was referring to MH concurrently manipulating more than one backend message store. E.g., a local message store, an IMAP store, and a POP store. First off, how to address folder addresses. Does +folder extend to +<scheme>folder? Or <scheme>+folder? Undoubtedly it's possible to torture the current syntax into submission, but practically it seems that adopting a URL-based syntax is the only things that makes sense. Preferably with a URL-aware context that permits abbreviations on the command line. Another concern is meta-data. MH annotates messages by adding headers to the message file. Messages in IMAP are immutable, so that won't work. But some IMAP servers support folder annotations which can be abused to provide similar message attributes. None of this can reliably survive a copy to a foreign message store. Likewise with hard links: they work in UNIX, but not in IMAP. How much functionality is it worth losing to support multiple message stores? Maybe it's time to review how and where the various bits of functionality are being used. The e-mail world today is a wee bit different from what we (well, some of us) grew up with. It could well be time to revisit how some of that functionality is implemented. It might be that the usage models have changed enough that some of the underlying implementation is no longer necessary. If we can free up obsolete bits of the UI this could make room for expansion into new namespaces and the like. --lyndon _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
