>the top of thread shows a prediction of likely performance impact from >opening and closing an imap session every time an mh command starts or >stops. i'm arguing against that, because state is necessary in order to >receive push notifications, and so to me, the reason to keep one long >lived imap connection open is more important than the performance we >could achieve without doing so.
I'm not AGAINST a longer-lived daemon, but ... well, it's more complicated. I mean, we need to write the IMAP protocol engine regardless of what we do; putting an additional abstraction layer would be a whole other pile of code (also, I'm not sure that the client<->daemon protocol wouldn't end up looking a lot like IMAP). And the helper daemons you mention (ssh-agent and gpg-agent) are not quite the same; they are adjuncts designed to hold authentication credentials so users don't have to keep typing in passwords. With the "almost no caching" model, things are much simpler; I mean, it's not like you get notified in a traditional MH mailstore that new messages have arrived. I'm not sure you really need push notifications, unless I am not understanding your ultimate goal (which is always possible). And yes, it is easy to come up with issues that make this implementation less than perfect. For example, assume that the UID-message number mapping is stored somewhere in ~/Mail. This means on systems without a shared home directory, every nmh instance would have it's own message number mapping (I would argue this is exactly how it is TODAY). Arbitrary sequences are a challenge unless the server allows unlimited flags, and not all do. Annotations (other than a basic "this was replied to") are VERY difficult. I feel these tradeoffs are certainly worth it for at least some kind of IMAP support, but of course if you do not agree then you are free to not use it! Or at the very least, use "refile" to bring the messages from your IMAP store into a local nmh store where you can get full functionality. >yes but i was envisioning an nmh-agent that abstracted all operations on >mh objects that would otherwise require locking -- not just keeping an >imap connection open for various mh commands to re-use. bad vixie. I ... can VAGUELY see how that might be useful. It's just ... finite amount of time! Let me say that I'm not envisioning doing anything that would PRECLUDE such a thing. We can target it for the nmh IMAP v2 implementation :-) --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
