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.
--lyndon
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers