nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Multiple Mailstore Support


From: Lyndon Nerenberg (VE6BBM/VE7TFX)
Subject: Re: [Nmh-workers] Multiple Mailstore Support
Date: Wed, 14 Oct 2009 20:55:46 -0600

> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]