Re: [Nmh-workers] Multiple Mailstore Support

[Joel Reicher]

"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