>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@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers