The document discusses the evolution of an email service, identifying issues such as isolation of Evolution Mail and the need for streamlined communication features. It proposes creating a lightweight email daemon using reusable libraries and a D-Bus interface to improve performance and integration with desktop applications. Future plans include developing a scalable web app and further enhancing integration with other software like Nautilus and LibreOffice.

1. Evolution
as
Email Service
Srinivasa Ragavan
sragavan@gnome.org
03 Aug 2013

2. Mail to EDS

3. Let me start with the problems...

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. This is how it will be

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. 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. How will it be done?

9. No we aren't killing Evolution!!!

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. 1
DBus API
• Core APIs
• EmailDataSession
• EmailDataStore
• EmailDataFolder
• EmailOperation
• Generated from xml using gdbus-codegen
• Needs more iteration and ideas for simple apis

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. What and all can be done?

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. Rich Lock screen integration
3 new emails from Matthew Barnes, Michael
Meeks and Robert Bradford

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. Power Nap kind of integration for Email

18. Stealth Screen notification center ?

19. Done & Pending?

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. 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. 2
Sources
• https://github.com/sragavan/e-mail-factory

23. Are you ready for the huge step? Questions?
Image credit authors