Re: [Nmh-workers] Future directions for nmh

[Ken Hornstein]

>You know this sort of thing falls well outside POSIX. It would be inside
>a non-portability #ifdef.

Heh, well, I just wanted to remind you of your previous opinions, that's
all :-)

>Actually, that's my preferred scheme.  But it's not trivial to do – on
>either side – so FUSE seemed like a more practical solution.

Personally I think just writing the code and linking into all of the programs
is the easiest.  But putting that aside now...

You bring up a fair point about mailbox changes during an existing
session.  It seems that's a concern when using message numbers; if
messages are referenced via UID, then that seems like we don't have to
worry about it; if messages are added we just ignore them during the
command (like we do now), if they are removed we deal with them like we
do now (basically, throw an error); as long as we fetch messages via UID
we don't have to worry about a message sequence number changing out from
under us.  I am aware that you're not required to support persistent
UIDs, but I think most IMAP servers do?  We could simply refuse to work
if the IMAP server does not support persistent UIDs.  It occurs to me
that since nmh commands are short-lived, it might not be a problem in
practice.

But here's the thing I really want to get at.  People bring up FUSE
as a viable interface for nmh to use for IMAP.  The point I'm trying
to make is: as far as I can tell, a FUSE interface to IMAP does _not_
solve the above problem; you still have to deal with it.  And I believe
it makes it WORSE; each nmh command starts with a brand-new scan of a
folder, so messages added or removed between commands work out fine.
But a FUSE interface would have no idea when an nmh command is starting
or stopping, so you'd have to do a lot of caching or a new IMAP session
for each file access.  The ONLY value of an FUSE IMAP interface I see is
that you wouldn't have to change base nmh code; I think any FUSE IMAP
interface would be more complicated than directly integrated code, and
hence it would be more buggy.

--Ken