So just to inject a slight simplification that for some of us matters.
Access to *READONLY* archives via IMAP is the killer app for me.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
>the prayer code base has been abandoned, but i still run it here, and i
>think MH could learn a lot from studying it. right now we store our mail
>and our state in the file system. that's called "legacy" now. i could
>live with always calling mhpath to get a file i can read/modify, even if
>Given all this it makes sense to me to start with the model of
>of a separate daemon. I think interfacing nmh commands with mhd
>will be much simpler than interfacing with a remote imap server.
Personally, I am not convinced this is true. But, please don't let my
concerns stop you! Really, I
Bakul Shah wrote:
...
The local socket part is easy. Connect to /tmp/mhd/$USER. [Calling
this daemon mhd for short] If the socket doesn't exist or a write to
it fails, kick off mhd.
indeed, yes, that's how to do it. see also "prayer", an imap server:
Prayer is yet another Webmail
On Oct 14, 2017, at 10:57 PM, Ken Hornstein wrote:
>
>> If common MH commands have to connect to an imap server & login every
>> time, people will notice the delay. May make sense to have a local
>> imap<->MH daemon. You then connect to it over a local socket. The daemon
>> makes
>One thought, when perusing offlineimap I noticed it said Gmail doesn't
>allow emails to be removed over IMAP in the normal manner. Instead, the
>label `\Trash' must be added to move it, allowing Gmail to clean up
>later. So not all IMAP servers are created equal, sadly, and that might
>be a bit
>scan +big-imap-folder last:200
>
>You're gonna notice.
If you look at the IMAP protocol, there are a ton of optimizations you
can do. For example, you could just extract the information you care
about. For example, this could be:
C: A001 SELECT archive
S: * 4 EXISTS
S: A001 OK SELECT
Hi Ken,
One thought, when perusing offlineimap I noticed it said Gmail doesn't
allow emails to be removed over IMAP in the normal manner. Instead, the
label `\Trash' must be added to move it, allowing Gmail to clean up
later. So not all IMAP servers are created equal, sadly, and that might
be a
On Sun, 15 Oct 2017 01:57:44 -0400, Ken Hornstein said:
> As for the delay ... well, my experience with message submission which
> involved authenticating to SMTP servers using similar protocols to IMAP
> showed me that a complete message submission took between 0.3 and 0.7
> seconds. This was
>If common MH commands have to connect to an imap server & login every
>time, people will notice the delay. May make sense to have a local
>imap<->MH daemon. You then connect to it over a local socket. The daemon
>makes it easy to add caching.
That HAS been discussed, but well, it increases
On Oct 14, 2017, at 9:34 AM, Ken Hornstein wrote:
>
>> What about storing sequence related info in a separate imap
>> folder in some fake messages? May be even as a MIME
>> attachments!
>>
>> 1. Basically map MH msg numbers to Mail-IDs + status in an
>> "index" email message.
>What about storing sequence related info in a separate imap
>folder in some fake messages? May be even as a MIME
>attachments!
>
>1. Basically map MH msg numbers to Mail-IDs + status in an
> "index" email message. May be one msg per folder.
>
>2. On any +folder access, this index email would
[Sorry for reviving an old thread. I subscribed recently & sampling
old threads]
On Sat, 08 Apr 2017 14:53:58 -0400 Ken Hornstein wrote:
> I know you know this already, Paul; I'm only repeating it for the
> benefit of others. The Big Problem with a nmh IMAP backend is how
13 matches
Mail list logo