[Top][All Lists]

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

Re: [Nmh-workers] MH + IMAP? (was Large MH directories

From: Ken Hornstein
Subject: Re: [Nmh-workers] MH + IMAP? (was Large MH directories
Date: Sat, 14 Oct 2017 12:34:19 -0400

>What about storing sequence related info in a separate imap
>folder in some fake messages?  May be even as a MIME
>1. Basically map MH msg numbers to Mail-IDs + status in an
>   "index" email message.  May be one msg per folder.
>2. On any +folder access, this index email would have to be
>   reconciled with any new or deleted messages.
>3. Initial connection and periodic checking would have to
>   similarly reconcile with new or deleted folders.
>4. Most MH commands should require no change if messages are
>   cached locally like now. Basically all local state would
>   turn into cache and real state stored on the imap server.
>5. An alternative would be to implement most of this in a
>   separate server & mount the "mailfs" it via fusefs. This is
>   somewhat analogous of plan9's upas. Such a server would
>   require no change in MH proper (or may be only for
>   delivery).

Some thoughts.

1) Anything involving FUSE: no, no, NO, NO!!!!  I have detailed my thoughts
   on this before, but as a recap: Massively unportable, extremely
   complicated, simply shifts the hard problems to a more complicated
   layer.  Let us speak of this no further (unless you want me to elaborate
   my thoughts on how terrible an idea this is).

2) In terms of implementation details .. I have waffled back and forth
   about whether or not to store some of the necessary indexing information
   on the IMAP server or locally.  It occurs to me that storing it locally
   would be easier to implement, at least for an initial implementation.

3) I think the EASIEST thing to do would be to simply access every
   message on the IMAP server directly, without any local caching.  I
   realize this isn't ideal, but to me the main issue is developer
   resources; doing local caching would complicate things tremendously,
   and that just means more time.  Maybe local caching for offline work
   could be v2 of the IMAP implementation.

4) I believe a number of operations would actually have improved performance;
   for example, having pick(1) push it's searches to the IMAP server would
   be a huge win.  Operations on a larger folder would probably work better.
   But how things would work overall in terms of performance?  We'd have
   to see.

>There are a number of benefits of doing this but an MH specific
>"storage" API would've to be defined first.

Yeah, that's part of the deal; I've proposed some simple ideas in that
direction on here before, but they're not well-formed.

I have managed to convince myself that there are no FUNDAMENTAL problems
with an nmh<->IMAP interface; we just need to roll up our sleeves and write
the code.  Sadly, lack of time is the issue there.


reply via email to

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