Architecture/planning/evolution-data-server/email-design

Revision as of 11:59, 16 June 2011

EMailFactory will be a dbus daemon, that runs camel session. The camel session controls the providers of IMAP/POP/Exchange/* and keeps checking emails, and serves CamelStore/CamelFolder/CamelMimeMessage/* over DBUS to its clients. Below is a high level architecture diagram of how the various pieces fit together, displayed below.

Source

The Camel Daemon code is now in gnome git, in the email-factory branch.
http://git.gnome.org/browse/evolution-data-server/log/?h=email-factory has the code the for the daemon:

The DBus API currently provided by the Daemon is below. In a high level, it is a async wrapper around the camel's session/folder/store API.
http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-folder.xml?h=email-factory
http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-store.xml?h=email-factory
http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-session.xml?h=email-factory

About Camel Daemon

Camel Daemon (The EMail factory) is a process that runs camel session. A high level picture of the daemon is below:

MeeGo Tablet mail integration

• Integrate Account setup with EAccountList/EAccount in Gconf.

It could be a challenge to verify accounts. As Evolution doesn't do that yet. It runs accounts and reports error if its not right.

• Deeply integrate the camel daemon's dbus api into the email app

Have the working C++ dbus interface for the Camel daemon, created working instances & marshaling code etc. Moved away the base objects of folderlistmodel, emailaccountlistmodel and emailmessagelist model from QMF baseclass to QAbstract*Model. Implemented these models to pick up data from Camel daemon. Modified a bit of QML set the folder/account correctly.
Pending:

1. Modify EmailAgent, in a way it send/receives mails to Camel
2. Modify EMailFeedModel to handle EmailMessage creation from Camel.
3. Integrate CamelMimeMessage & mime part hierarchy for things like attachment handling, plain text and html body.
4. Composer integration & sending mails.
5. Mail operations handling: like create/delete mail/folder, reply/forward, mark read/unread, sort, search.

• Camel API:

Almost complete to suffice our need, have a test code that runs through all the APIs and work well so far. Expect a few minor changes here & there on demand.

Pending:

1. Write libcamelremote a wrapper around the DBus interface to provide sync/async apis for the camel Daemon.

• Camel Daemon:

Works mostly, and is pretty stable than expected. But should spend some time & check on the CPU usage,dbus connection handling, and object clean ups.

1. DBus conneciton handling & object clean ups.
2. EMail preview support. Anjal used to extend evolution to add email preview of unquoted text. I should add
   that bit to Camel so that it can be served to the tablet email app.
3. Gtk free the daemon. Specially the password dialog. Add signal to integrate with clients for password handling. Add better error handling and progress reporting.

QtMobility support

3rd party apps will use QtMobility to interface with email framework than the raw DBus apis.

The QtMessaging module is a QtMobility module providing access to messaging services.

In order to provide implementation of QtMessaging interfaces a new dynamic library should be created.
The library should be loaded into email client application process.
The library should expose QtMessaging interfaces and map QtMessaging api to Camel daemon dBus api.
Possibility of direct read from Camel local storage shall be discussed.

The analysis of how QtMessaging interfaces can be implemented via Camel back-end is shown on table below.