"Lyndon Nerenberg (VE6BBM/VE7TFX)" writes: > > 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.
Firstly, I should confess I don't have time to do any MH work at the moment, although I would *really* like to. Anyway, here are my thoughts. POP is not a mailstore. There exist mail operations in MH that do not fit naturally onto the POP model, and in fact may not be possible with POP at all. inc is what is used for POP, and I don't think there's any reason to change that. More generally, inc operates on a maildrop. POP is a maildrop. IMAP is a mailstore. I think the maildrop/mailstore distinction is important and the way it's currently handled should not be changed. It might be easier to extend MH to alternative local mailstore formats than jump straight to IMAP. A mailstore format already in use by an IMAP server seems an obvious choice... http://wiki.dovecot.org/MailboxFormat/Maildir This kind of work would tease out the issues in abstracting store operations in the existing MH code without requiring quite so much new code. > 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. I think an extension of the folder selection syntax is the only sensible option, and although the new syntax should be chosen carefully it's not a technical issue and can be deferred. > Another concern is meta-data. MH annotates messages by adding headers > to the message file. Headers aren't meta-data; they belong to the message. Not to the body of the message, of course, but still to the message. In MH, sequences are meta-data, as is the path to the message. > 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. anno modifies the message, and so the appropriate implementation in IMAP would seem to be a deletion followed by the creation of a new message. This causes problems for inplace annotation, but this is not a new problem. AFAICT, at the moment a refile -link attempted across filesystems fails silently. If we think there's nothing wrong with that on local filesystems, there does not seem to be anything wrong with presenting an IMAP store as one that doesn't support links between any folders. Cheers, - Joel _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
