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