On 8 September 2000 at 18:02, John Reinhagen <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, also sprach Iain
> MacDonnell:
>
> >Jerry Peek writes:
> >: I haven't thought a lot about internals here... but couldn't an IMAP
> >: implementation just store its sequences in the context file (by
> >: default, ~/Mail/context)? This is what commands like "mark -nopublic"
> >: do. All nmh commands can access these sequences.
...
> However, there's a more fundamental bug: The entire
> advantage of IMAP lies in storing parts of one's email environment -- unseen
> messages, etc. -- on a central server that one can access from anywhere.
> Storing sequences on local filesystems violates that idea to the extent that
> people consider sequences to be a part of their email environment.
I don't know enough about IMAP to give a good answer about this.
I'll write some comments and hope they're useful as food for thought.
In nmh, multiple users can share the same mail folder. Each user
typically has their own private context for that shared folder stored
in their own $HOME/Mail/context file. So different users can see a
different view of that folder's sequences. The same would be true for
one user who accessed a folder on an IMAP message store from multiple
hosts: the user would have different context at each host, and that's
the way it would be. As another example, Unix filesystem permissions
might deny a user access to some of the mail folders they might want
to read -- and IMAP access permissions (no access to a remote host,
etc.) might keep someone from seeing their IMAP store.
Then there's the question of a "session": doesn't IMAP have the idea
of "logging on" or "connecting" to an IMAP store for some period of
time, and preserving the state of that session while the user is
logged on? (In the same way that traditional email programs are either
running or they aren't?) Of course, nmh doesn't work this way: you can
run any nmh command from anyplace (any terminal, any script, etc.) at
any time. Then you can go away for days and come back and type "repl"
and expect to reply to the same message in the same folder you were
reading days ago. The system can even be rebooted; the context
(current message, current folder, sequences) is preserved. I don't
think IMAP works that way. For instance, with IMAP/nmh, could I type
"show" in one window, then move to another window to type "repl", then
go back to the first window and type "next" while "repl" is still
running in the second window? Would that be opening two separate IMAP
"sessions" and confuse the IMAP server between the two windows?
Maybe there's some kludge that could be tacked onto an nmh/IMAP
implementation that would store the extra nmh info in a fairly
compatible way? For instance, does IMAP have a pigeonhole somewhere
(a folder with a name that nmh users reserve, or something) that
could store a user's context info (from $HOME/Mail/context and
<folder>/.mh_sequences) -- and that info could be copied to/from
the IMAP store with each MH command? You'd need to do some locking
that could make nmh commands block (and even time out?), but it
might work.
It's great that people are considering this. But I hope that whoever
implements it has experience in using raw nmh to its limits -- not
only the experience of using a limited GUI single-user single-session
email program that uses nmh as a back-end. For nmh at its limits,
see Chapter 9 <http://www.ics.uci.edu/~mh/book/mh/tocs/mhyrwy.htm>
and Chapter 13 <http://www.ics.uci.edu/~mh/book/mh/tocs/uprmh.htm>
of the MH book. For info about how nmh stores its context, see
Chapter 2, <http://www.ics.uci.edu/~mh/book/overall/tocs/keyparts.htm>.
And Chapter 2 has a figure with an overview of nmh uses of filesystem
in <http://www.ics.uci.edu/~mh/book/overall/figs/impoaunf.jpg>.
I wish I knew more about the intricacies of IMAP; I've only used it in
"clueless mode" ;-) from a GUI front-end and hacked it with JavaMail.
And sorry if this is obvious; I'm not trying to "talk down" to anyone!
I'm just trying to share my (almost) 20 years of experiences with MH.
My "gut feel" is that there may not be a perfect one-to-one mapping
between nmh/exmh and IMAP. Some things may have to bend. I just
hope that the implementation can preserve most of the strengths and
flexibility of nmh: it's the only email system with all this power,
and it'd be sad for the de facto IMAP implementation to hobble nmh.
(I'm not saying people want to hobble nmh; these are just thoughts.)
Whew. ;-)
Jerry
--
Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
