Evolution as Email service


Published on

GUADEC talk about Evolution mail as desktop service.

Images used in the presentation credit Authors.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Evolution as Email service

  1. 1. Evolution as Email Service Srinivasa Ragavan sragavan@gnome.org 03 Aug 2013
  2. 2. Mail to EDS
  3. 3. Let me start with the problems...
  4. 4. Here they are • Evolution mail is isolated. No interfaces at all. • Since GMail, there is only one big INBOX and that adds problems like memory usage and so can't keep it running it all the time. • Need for (e)lite services like new mail notification, idle download and smart inline reply etc • Applications nautilus-sendto , Libreoffice need Evolution to be started for sending emails.
  5. 5. This is how it will be
  6. 6. When you boot up • A small background process called e-mail-factory starts up and checks if you have any email accounts, if not it quits. • You go to Control Center->Online Accounts (or somewhere there) create a Gmail account or Yahoo account or your corporate account and say you want Email, Contacts and Calendar. • Once the account is configured and created, it starts up the e-mail- factory process, if it is not running already • It sees the list of account, authenticates with them with the help of stored password, download basic stuffs like list of folders, unread/total email count and at the back ground download summary for INBOX and other folders or just configured folders and filters them, checks for spam etc.
  7. 7. When you boot up... • Once everything is downloaded and stored locally, it goes back to rest with a open connection for PUSH email or checks emails at intervals. • When a new email arrives, it downloads them and notifies the desktop • Notification bubble shows the email and the user clicks on the email and a viewer with inline reply opens up (not the email app) and closed when done. • If you want to check for other mails, you kick start the email app and list down the INBOX mails from the daemon and you search for the mail, read and close. The email daemon goes back to connection only state. • Notification area for missed new emails.
  8. 8. How will it be done?
  9. 9. No we aren't killing Evolution!!!
  10. 10. 0 This is how it is done • Evolution is a BEAST. Split mail in to small reusable library outside of Evolution. Libemail-engine which has the core email logic. • A Daemon that runs accounts created with the libemail-engine and checks for mails, downloads necessary things and stores them. • Expose a DBUS interface that gives access to Store/Folder/Summary /Emails. • When a client application starts, it uses DBUS to get list of Stores and Folder information (unread/total count) from the email daemon. When the user clicks on store get the list of folders and then mails as and when required. A state less API to keep it light at the deamon side. • Pass mails via message passing over FD (to avoid any hog) • Move composer & renderer as separate independent libraries.
  11. 11. 1 DBus API • Core APIs • EmailDataSession • EmailDataStore • EmailDataFolder • EmailOperation • Generated from xml using gdbus-codegen • Needs more iteration and ideas for simple apis
  12. 12. 2 Possibly with • Mails via message passing over fd. • Optional client side SQL/sqlite direct access for summary read & fetch. • Need to figure out any other possible performance hogs & improvement ideas.
  13. 13. What and all can be done?
  14. 14. 4 Like... • A light weight web app that lists pages of emails that can scale up to any size without any issue. • idle download of messages, deeper integration into the desktop. • Send emails or view emails without launching any app • Search for attachments, emails outside of email application • Provide faster experience with pre-downloaded emails • Nautilus can email without having the mail app opened/running (better nautilus-sendto) • Libreoffice integration
  15. 15. Rich Lock screen integration 3 new emails from Matthew Barnes, Michael Meeks and Robert Bradford
  16. 16. Notification with inline reply support 3 new emails from Matthew Barnes, Michael Meeks and Robert Bradford Matthew <mbarnes@redhat.com> Hacking plans? Hi Srini, Do you want to join the hackfest on Monday. Reply with interesting bugs. Reply Inline
  17. 17. Power Nap kind of integration for Email
  18. 18. Stealth Screen notification center ?
  19. 19. Done & Pending?
  20. 20. 0 Done • Evolution broken to reusable email libraries. Libemail-engine committed in 3.4 cycle. • E-mail-factory built on top of libemail-engine and runs evolution accounts (ported upto 3.6) • A bare DBUS api similar to the camel interface available via gbus- codegen. • A regression suite that runs the list of completed api and tests them.
  21. 21. 1 Pending? • A sugar coded libemail library over the DBUS interface • A improved api with things client side sqlite fetch & search. • Make Evolution use the e-mail-factory to start with and move libemail- engine to EDS. • Move composer & renderer as separate library to EDS • Lets write a fresh & lite email app on top of GNOME 3 (like Anjal)
  22. 22. 2 Sources • https://github.com/sragavan/e-mail-factory
  23. 23. Are you ready for the huge step? Questions? Image credit authors