|Subject:||Re: [Nmh-workers] What is MH ?|
|Date:||Wed, 11 Jan 2006 13:12:46 -0800 (PST)|
I believe that IMAP support should be done mapping the files in the mail server on a local in-memory filesystem as MFS, tmpfs, kernfs or procfs do.
I disagree completely. The biggest appeal of MH, to me, is that it is a natural "offline" IMAP client. If you restrict yourself to a temporary in-memory representation of the IMAP server, you lose any ability to maintain state across "sessions."
The advantage of using an IMAP "connector" (for lack of a better term) is that you gain the ability to work naturally in a disconnected mode. In effect you can treat the local MH store's view of the IMAP server as an offline cache. In it's simplest (functionally speaking) mode, inc would gain a -sync flag that would synchronize the local folder view with the server's state. This is trivial to do, since MH's message-file names naturally map to UIDs on the IMAP server. There might be issues surrounding 'folder -pack' as that would become a noop; Do any of you have applications that would break if this was the case?
The second advantage of the "connector" is the ability to take advantage of IMAP annotations in support of anno. I don't see how this could be achieved in the filesystem model, since the messages files are read-only in that context.
|[Prev in Thread]||Current Thread||[Next in Thread]|