[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Future directions for nmh

From: Ken Hornstein
Subject: Re: [Nmh-workers] Future directions for nmh
Date: Wed, 16 Mar 2016 19:56:35 -0400

>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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]