Webmail
So I've been writing some webmail stuff - braindump time!
After wrestling Horde/IMP, Roundcube, AtMail Open, and so many webmail clients around the place it's not funny the conclusion is that none of them do what I want: modern, fast, efficient webmail. That means gracefully-degrading REST/DRY/AJAX/AcronymOfChoice interface using persistent connections, sensible caching, etc.
The end product should be a nice, clean webmail client which gives you flexible configuration options. It should be just as easy to setup a webmail interface to a single mailbox which requires no authentication as to provide a sophisticated multi-account, multi-mailbox setup. A user should be easily able to log in, view mailboxes, read mail, etc. Someone visiting via Lynx should get all the same functionality as someone using Google Chrome, but the Chrome experience will be slick, AJAXy and and show new mail when it arrives without a reload, etc.
The server should be clever. It should figure out the best caching and pre-fetching strategy for your configuration *at start-up time*. It should be event-driven. It should use IDLE/NOTIFY on IMAP connections and publish back to clients using COMET.
This is a tall order! There are many considerations. PHP is out - it's not persistent, let alone event-driven. Perhaps it could be used for the templating, though. What about if there was an additional IMAP gateway? *It* could be event driven, use persistent IMAP connections, do the IDLE/NOTIFYing, caching and pre-fetching, etc. But how would PHP and the gateway communicate? How about via JSON? This gives us the added benefit of providing an AJAX-compatible data source for all mail operations. Nice! So advanced clients can AJAXify the page and talk directly to the gateway.
But IMAP is just one protocol. The JSON gateway should provide a fairly abstract interface which the webmail application can use, with a backend optimised for each protocol. It may even be better to write direct implementations instead of using too abstracted libraries (like libcamel, libtinymail, etc) as it would let us know that "get folders" means "update the folder navigation, including # unread messages" so we need folder names, hierarchy and unseen count. These can be optimised per backend (IMAP/POP3/Exchange?/filesystem[mbox/Maildir(++)/dbox/..]).
So at the moment I'm hacking something together in PHP using a fairly abstract interface. There are plenty of PHP-hating moments, but it's a great RAD tool. Also, you'll be able to drop it on pretty much any PHP-compatible web server and have it work. When you hit scalability problems, install the PECL mail extension. When you run into problems again, install the gateway. Maybe then offer a complete stack written in something like event-driven C? How about making the JSON gateway part of the mail server accessing mail directly?
It's time for webmail to be done properly in a way that's useful to everyone. Additionally, we need a free, open-source Gmail/Google Calendar/Google XYZ stack - this is a start!
More to come!
After wrestling Horde/IMP, Roundcube, AtMail Open, and so many webmail clients around the place it's not funny the conclusion is that none of them do what I want: modern, fast, efficient webmail. That means gracefully-degrading REST/DRY/AJAX/AcronymOfChoice interface using persistent connections, sensible caching, etc.
The end product should be a nice, clean webmail client which gives you flexible configuration options. It should be just as easy to setup a webmail interface to a single mailbox which requires no authentication as to provide a sophisticated multi-account, multi-mailbox setup. A user should be easily able to log in, view mailboxes, read mail, etc. Someone visiting via Lynx should get all the same functionality as someone using Google Chrome, but the Chrome experience will be slick, AJAXy and and show new mail when it arrives without a reload, etc.
The server should be clever. It should figure out the best caching and pre-fetching strategy for your configuration *at start-up time*. It should be event-driven. It should use IDLE/NOTIFY on IMAP connections and publish back to clients using COMET.
This is a tall order! There are many considerations. PHP is out - it's not persistent, let alone event-driven. Perhaps it could be used for the templating, though. What about if there was an additional IMAP gateway? *It* could be event driven, use persistent IMAP connections, do the IDLE/NOTIFYing, caching and pre-fetching, etc. But how would PHP and the gateway communicate? How about via JSON? This gives us the added benefit of providing an AJAX-compatible data source for all mail operations. Nice! So advanced clients can AJAXify the page and talk directly to the gateway.
But IMAP is just one protocol. The JSON gateway should provide a fairly abstract interface which the webmail application can use, with a backend optimised for each protocol. It may even be better to write direct implementations instead of using too abstracted libraries (like libcamel, libtinymail, etc) as it would let us know that "get folders" means "update the folder navigation, including # unread messages" so we need folder names, hierarchy and unseen count. These can be optimised per backend (IMAP/POP3/Exchange?/filesystem[mbox/Maildir(++)/dbox/..]).
So at the moment I'm hacking something together in PHP using a fairly abstract interface. There are plenty of PHP-hating moments, but it's a great RAD tool. Also, you'll be able to drop it on pretty much any PHP-compatible web server and have it work. When you hit scalability problems, install the PECL mail extension. When you run into problems again, install the gateway. Maybe then offer a complete stack written in something like event-driven C? How about making the JSON gateway part of the mail server accessing mail directly?
It's time for webmail to be done properly in a way that's useful to everyone. Additionally, we need a free, open-source Gmail/Google Calendar/Google XYZ stack - this is a start!
More to come!