On Thu, Dec 14, 2023 at 07:17:16PM +0200, Timo Sirainen wrote:
I wonder if this debounce delay was added as a workaround for an internal Dovecot bug or a client bug and is not necessary anymore. It does not seem to be useful for well-behaving clients because if necessary the client may debounce notifications on its side and postpone interrupting IDLE with "DONE".
I can't really think of any situation where this would be necessary anymore. Not sure why it was necessary back in 2009 - maybe Maildir didn't have quite as many locks back then. Anyway now even if a change is partial at the time the mailbox-watch triggers, it runs full mailbox syncing which will lock the mailbox, so it waits for any previous changes to finish being written.
I have only tested with Maildir, maybe it was important for some other storage at the time it was introduced.
I would actually like to disable this delay completely on our server setup [6], as for chat it is common to receive multiple messages in a short period of time, e.g. when sending a message to a group and receiving multiple read receipts from currently active users.
We could of course make this a setting, but maybe it's not necessary. Would this behavior also work for you? :
- If the current IDLE hasn't notified anything yet, send the notification immediately without waiting
- Otherwise, send it max once per 0.5 seconds.
For IDLE this would work and be indistinguishable from no delay as Delta Chat core always interrupts IDLE with DONE as soon as it receives a response (e.g. EXISTS or RECENT, but not keepalive).
But as this delay code is a part of the storage (src/lib-storage/mailbox-watch.c) and knows nothing about IDLE, I am not sure how this could be implemented. There is also a plan to implement NOTIFY (RFC 5465) extension support in Delta Chat [1] where "NOTIFY SET" is executed only once and then there are incoming notifications for the rest of the IMAP session. NOTIFY uses the same callback and has the same 0.5 second delay as a result.
What could work is a change to callback immediately if there have been no callback call in the last 0.5 seconds and otherwise delay it. Then there will be no difference as long as two emails in a row do not come wihin half a second.
But I also wonder why not remove the delay completely then if there is no need for it? Debounce can always be implemented on the client side if necessary, if the client does not want to react to interruptions more frequently than once every half a second it can delay the reaction locally.
So if you're using the same connection to always break out of IDLE after a notification, there would be no dalays.
[1] https://github.com/deltachat/deltachat-core-rust/pull/4990