Re: [Nmh-workers] What is MH ?

[Lyndon Nerenberg]

> > 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