Repository navigation
Instant updates (push notification support) #6544
Description
The old solution for instant notifications about changes in mailboxes is IMAP IDLE. This has however a big limitation which is a need to use a separate IMAP connection for every folder.
Recent versions of dovecot and cyrus provide APIs that could be used and might be better than IDLE. For example:
- https://jmap.io/#push-mechanism
- https://www.cyrusimap.org/imap/concepts/features/event-notifications.html
- https://wiki.dovecot.org/Plugins/PushNotification
So, here's an idea how we could use it. A Roundcube plugin containing two components:
- Websocket client (frontend) that receives signals from backend and updates the UI.
- Websocket+HTTP service (backend) that handles connections from imap notification services and passes them to the frontend (with some format conversion or other logic).
The frontend part would be simple javascript code. It could receive simple messages like general "refresh folder X unseen count", "refresh folder X's messages list" or depending on the other part it could be more precise "set folder X unseen count to Y" or "Mark message X as seen". The frontend don't need to know about what type of notification system is used by the backend.
The backend part will be more complicated. I'm not sure it should be in PHP, but probably with libraries like Swoole it would be doable (https://www.swoole.co.uk/docs/modules/swoole-websocket-server). It would receive notifications from all kind of notification services with some driver-based API. All kind of notification formats would be converted to some internal format understood by the frontend and passed to it via websocket.
In cases when the notification does not contain all information, e.g. when it says "a message has been marked as seen", but not "how many unseen messages in that folder left", the backend could (having access to Roundcube session, i.e. user credentials) fetch the missing information from IMAP. But we can probably just fallback to asking Roundcube to do that request by itself.
Activity
Push plugin (#6544)
alecpl commentedon Jan 7, 2019
Proof-of-concept in https://github.com/roundcube/roundcubemail/tree/dev/push/plugins/push. Any help will be appreciated.
HLeithner commentedon Feb 8, 2019
Really interesting idea, did you considered reactphp? I did paid work with it last year and it was really easy and stable to use.
Have you checked if dovecot web would support websockets directly?
alecpl commentedon Feb 8, 2019
Nope. I didn't test reactphp and I didn't try dovecot yet. Replacing the engine from Swoole to something different should not be that hard, so we might consider that change in future if we have issues with Swoole. I didn't yet really test performance nor reliability of Swoole based solution.
FingusDE commentedon Mar 21, 2019
I´m using the html5-Notifier-Plugin (https://github.com/kitist/html5_notifier). It seems your Project will replace it in a better way.
HLeithner commentedon Mar 21, 2019
@FingusDE the plugin you mention does something complete different Aleksander talk about the imapserver<->webserver push notification this would trigger your mentioned plugin.
FingerlessGlov3s commentedon Nov 30, 2020
@alecpl Any news on this getting updated on master?
alecpl commentedon Nov 30, 2020
Nothing changed since the proof-of-concept. I have other priorities right now.
InterLinked1 commentedon Jul 31, 2023
These are specific to these mail servers though and don't generalize. Rather than catering to Dovecot and Cyrus, I think it would be better to, apart from supporting
IDLE, support theNOTIFYextension, which is a standard IMAP extension that is much more widely supported (though not as much asIDLE, which is ubiquitous now).Otherwise, the proof of concept sounds like a good start to me. Over the past couple months, I wrote my own webmail software[1] for my own use, since I wasn't satisfied with any of the existing ones. Like some previous discussion[2] and this issue suggests, it uses WebSockets so the frontend can maintain a persistent connection to the backend for the whole connection. There is no AJAX or polling used at all. The backend uses
IDLEand/orNOTIFYwith the IMAP server so users can get realtime notifications about activity in all of their mailboxes.I don't think the backend actually needs the user credentials, technically, depending how you implement it. Obviously it needs to be passed them for the IMAP login at the beginning, but once the connection is set up, it can just keep using that. Ideally, just the one connection is sufficient for everything, e.g. one can stop the
IDLE, issue aSTATUS, and then resumeIDLE.I initially prototyped my backend in PHP, but I quickly gave up and did everything in the backend in C because all the IMAP libraries for PHP suck, feature and performance wise, at scale, and I didn't want to write my own PHP library. So far it works great and I can't imagine doing it any other way now. Polling in a webmail application in 2023 is antiquated and a poor user experience, when time is people's most important resource. Obviously, most webmail programs were written prior to WebSocket support, so they haven't had the benefit of starting fresh, but this would be, in my opinion, probably the single most useful enhancement to any current webmail package.
[1] https://github.com/InterLinked1/wssmail
[2] #1813