Overview
Many protocols has integrated email notification feature. Usually, email notification is done through polling by a email client. The IM's email notification is an interesting feature since it allow getting notified of incoming mails without the full round trip to the server. The IM server simply send a signal telling you information about unread mail that just arrived.
For reviewers, a draft of the API is available at http://people.collabora.co.uk/~nicolas/telepathy-spec-email_notification/spec/org.freedesktop.Telepathy.Connection.Interface.MailNotification.DRAFT.html. You can put you comments on https://bugs.freedesktop.org/show_bug.cgi?id=13349 or discuss it with me on #telepathy, I'm stormer.
Protocols
The biggest problem is that every protocols that support this feature has there own specific level of information. The Telpathy Email Notification spec aims at integrating as many as possible features while giving good hint to the user on what is and is not support by the Connection.
As a first step, the API will divide two things that usually comes independently in protocols: the Unread Status and the New Emails Notification. The Unread Status is defined as a mechanic that allow tracking information about messages (or threads) in folders of your email account. Currently no protocol support other folder then Inbox, but we will keep it in mind in the design to make sure the expansion would not be too hard. The Unread Status information should be updated based on newly arrived emails or modification of the unread status in the server database. While this is the full solution (currently only implemented by GTalk), some protocol have partial implementation of it. Refer to table titled Unread Status Support for a list supported feature by known protocols. Note that some protocol may just give initial information and not update it after all. Protocol Developers should not try to emulate any unsupported features, it's UI Developer's job to figure out how to display this information in a consistent way.
The New Emails Notification is generally done in a fire and forget way. For this reason, it would be a great overhead to force the Protocol implementer to store this information into properties. This would also lead to leaky design since there is no good solution to when the older notification should be discarded. Refer to the table New Emails Notification for list of what is supported per protocols. Note that protocols with sufficiently complete Unread Status support does not have to support this feature.
Unread Status
Protocols |
Unread Count |
Froms |
Tos |
Subjects |
Quote |
Inbox URL |
Email URL |
Cookie |
Updated |
MSN |
Yes |
No |
No |
No |
No |
Yes |
No |
No |
Yes |
Yahoo |
Yes |
No |
No |
No |
No |
Yes |
No |
Yes? |
? |
GTalk |
Yes |
Yes |
No |
Yes |
Yes |
Yes |
Yes |
No |
Yes |
Jabber |
No |
No |
No |
No |
No |
No |
No |
No |
No |
Yes |
Yes 2 |
Yes 2 |
Yes 3 |
No |
Yes |
Yes 2 |
No |
? |
Note: Most protocols are documented from libpurple source base, information may be inaccurate or incomplete.
2 Very often this feature is emulated
3 Optional and often omitted
New Emails Notificiation
Protocols |
Froms |
Tos |
Subjects |
Quote |
Folder URL |
Email URL |
MSN |
Yes |
No |
Yes |
No |
Yes |
Yes |
Yahoo |
Yes |
No |
Yes |
Yes |
Yes |
No |
GTalk |
Yes |
No |
Yes |
Yes |
Yes |
Yes |
Jabber |
No |
No |
No |
No |
No |
No |
Yes |
Yes 2 |
Yes |
No |
Yes |
Yes 3 |
MSN
MSN provide three message that let you keep track of the unread message count. It's not possible to maintain detailed list about all unread messages because the protocol does not send it. Also, when a message is marked read or deleted, you get a notification but it's not possible to match with a specific new mail notification. For this reason, MSN is a candidate to implement both the unread status (with only unread count information) and the fire and forget new e-mails notification.
Information to forward (Unread Status):
- Unread Count (protocol provides counts for Inbox and Other, to be considered)
Information to forward (New Emails):
- Sender (display name and address)
- Email URL
- Subject
More details about MSN Notification at [http://www.hypothetic.org/docs/msn/notification/messages.php].
Yahoo
TODO
Google Talk
Google provides an extension to XMPP to allow e-mail notification. Google email notification differs from other protocols because it does not provide notification about e-mails, but threads. The biggest difference between an email and a thread is that a thread has multiple senders, and within that list of senders you can have multiple unread senders.
One could consider the first unread sender to be the only useful information, but let say you are getting hundreds of messages with many threads every day. You probably don't go read you e-mails every time there is unread message. At the same time, if somebody that more meaningful to you sends a reply (e.g. like your boss) you may consider reading your mails.
Google Talk does not have a fire and forget New Email notification. This is mainly unneeded since full information about unread threads is send. This protocol should not implement the New Emails signal.
Information to Forward:
- Inbox URL
- Email type as 'thread'
- Last update timestamp
- Thread URL
- Unread Senders display name and address
- Subject
- Snippet from the body (currently HTML encoded)
More details about Gooble Talk Email Notifcation found at [http://code.google.com/intl/fr/apis/talk/jep_extensions/gmail.html]
Jabber/XMPP
Jabber/XMPP does not have standard email notification.