Mpozdnyakov (Talk | contribs) (→QtMobility support) |
Mpozdnyakov (Talk | contribs) (→QtMobility support) |
||
| Line 85: | Line 85: | ||
|Does not exist | |Does not exist | ||
|Should be implemented from scratch | |Should be implemented from scratch | ||
| - | |QtMessaging allows not support it or support partially.<br> Should store search parameters and QMessageManager class should | + | |QtMessaging allows not support it or support partially.<br> Should store search parameters and QMessageManager class should consider them while accounts querying. Implementation of logical operators is the most difficult part.. |
|- | |- | ||
| Line 99: | Line 99: | ||
|QtMessaging allows not support it or support partially.<br> Easy-to-implement object. Should store sorting mode and QMessageManager class must consider it while account querying. | |QtMessaging allows not support it or support partially.<br> Easy-to-implement object. Should store sorting mode and QMessageManager class must consider it while account querying. | ||
| + | |- | ||
| + | |QMessageAddress | ||
| + | |CamelInternetAddress | ||
| + | |Needed functionality (email address parsing) is supported. | ||
| + | |CamelInternetAddress can be mapped to QMessageAddress (alternatively QMF code could be used) | ||
| + | |||
| + | |- | ||
| + | |QMessageContentContainer | ||
| + | |Camel.MessageContentInfo | ||
| + | |Needed functionality is supported. | ||
| + | |Camel.MessageContentInfo can be mapped to QMessageContentContainer. | ||
| + | |||
| + | |- | ||
| + | |QMessageContentContainerId | ||
| + | |CamelMessageContentInfo->id | ||
| + | |Should be implemented from scratch | ||
| + | |Easy-to-implement object. Will contain 'CamelMessageContentInfo->id' inside | ||
| + | |||
| + | |- | ||
| + | |QMessageFilter | ||
| + | |Camel.FolderSearch | ||
| + | | | ||
| + | * Inter-folder search is missing. (Srini, could you clarify whether vFolder can solve it?). | ||
| + | * Searching of messages by parent/ancestors folder id is missing. | ||
| + | * Searching of messages by parent account id is missing | ||
| + | |QtMessaging allows not support it or support partially.<br> QMessageFilter should obviously be mapped to ESExp (where it is possible). Implementation of logical operators should also fruit resulting ESExp.<br> Challenging case here is combination of search via ESExp and self-implemented search (i.e. by ancestors folders). | ||
|} | |} | ||
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.
Contents |
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
Camel Daemon (The EMail factory) is a process that runs camel session. A high level picture of the daemon is below:
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.
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:
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:
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.
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.
| QtMessaging interface | Implementation in Camel back-end | Missing features | Solution |
|---|---|---|---|
| QMessageDataComparator | Does not exist | Should be implemented from scratch | Simple aux object. QMF implementation can be used. |
| QMessage | Camel.MessageInfo CamelMessageInfoBase | Message flags are different. Some properties are missing but can be calculated. | Camel.MessageInfo can be mapped to QMessage. |
| QMessageAccount | EAccount | Needed functionality is supported. | EAccount can be mapped to QMessageAccount |
| QMessageAccountFilter | Does not exist | Should be implemented from scratch | QtMessaging allows not support it or support partially. Should store search parameters and QMessageManager class should consider them while accounts querying. Implementation of logical operators is the most difficult part.. |
| QMessageAccountId | Eaccount->uid | Should be implemented from scratch | Easy-to-implement object. Will just contain 'Eaccount->uid' inside |
| QMessageAccountSortOrder | Does not exist | Should be implemented from scratch | QtMessaging allows not support it or support partially. Easy-to-implement object. Should store sorting mode and QMessageManager class must consider it while account querying. |
| QMessageAddress | CamelInternetAddress | Needed functionality (email address parsing) is supported. | CamelInternetAddress can be mapped to QMessageAddress (alternatively QMF code could be used) |
| QMessageContentContainer | Camel.MessageContentInfo | Needed functionality is supported. | Camel.MessageContentInfo can be mapped to QMessageContentContainer. |
| QMessageContentContainerId | CamelMessageContentInfo->id | Should be implemented from scratch | Easy-to-implement object. Will contain 'CamelMessageContentInfo->id' inside |
| QMessageFilter | Camel.FolderSearch |
| QtMessaging allows not support it or support partially. QMessageFilter should obviously be mapped to ESExp (where it is possible). Implementation of logical operators should also fruit resulting ESExp. Challenging case here is combination of search via ESExp and self-implemented search (i.e. by ancestors folders). |