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
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers