[sugar] SOC 2008 Proposal: Email activity for the XO

[Shikhar]

Need, Introduction
===================

Currently there is a Gmail activity but no real email client that can be 
used in Sugar. The possibility of accessing/composing emails offline 
does not exist.  An email client with mesh integration like direct 
sending to mesh buddies would be great, but the basic groundwork of a 
usable email activity is needed.

I think collaboration tools are a very important part of the OLPC 
software bundle and an activity which brings email to the XO desktop and 
ties in with the environment would be a great addition.

Deliverables
=============

* Lightweight, functional email client with a child-friendly GUI that 
centers email organization around tags and not folders; featuring 
search, filtering, threading, a basic address book, and easy configuration

* A daemon would also be developed for sending of unsent messages and 
receiving of new email. [Rationale: We can't assume the child will open 
the email activity when internet access is available.]

Ideas
======

* MIME parsing / message construction

Use the RFC-compliant Python <email> module for MIME parsing of incoming 
email and message construction. At this stage of development only 
plaintext and MIME-encoded unicode composition would be supported.

* Email sending/receiving

Utilize the RFC-compliant Python libaries <smtp>, <poplib>, <imaplib> 
for email sending/receiving. The daemon and the activity will share this 
code.

* Service descriptors

Make it very easy to configure on first run for services such as gmail. 
The service descriptor would contain details about servers, protocols, 
junk-headers provided by the service, etc. Thus the only information 
required upon selection of a service sould be username and password.

It should be possible to specify certain details in the service 
descriptor such as whether the service sets SpamAssassin headers, which 
IMAP folders are not to be downloaded. For example the Gmail service 
descriptor could specify that email in the 'All Mail', 'Spam' and 
'Trash' folder is not to be downloaded, and that other folder names are 
to be interpreted as tags, since Gmail provides IMAP.

An appropriate file format would have to be formalized.

* Central idea for email organization

Email will be organized around tags, much like Gmail's labels. An 
incoming email is tagged 'Inbox'. Sent emails are tagged 'Sent'. Deleted 
emails stripped of other tags and given the 'Trash' tag. When email 
sending is attempted without internet access, tagged 'Unsent'. Draft 
emails are tagged 'Draft' and a journal entry is also created for them.

Managing tags and applying a tag should be intuitive and easy. For 
instance dragging-and-dropping the visual representation of a tag onto a 
message should apply it.

* Storage

Develop an abstraction layer for storage-related requests 
[addMessage(Message), getMessage(id), getMessageIDsForTag('inbox'), ....]

Use <pysqlite> for mail storage in a sqlite database instead of 
traditional mailbox formats; no folders for organizing email. Email 
messages are MIME-parsed and stored as strings; attachments are detached 
and stored as files. There will be several tables in the database to 
keep performance good while minimizing redundance.

Using a database for email storage is not a new idea, here is an account 
of someone's succesful experiment for his purposes: 
http://www.sqlite.org/cvstrac/wiki?p=ExperimentalMailUserAgent

* Message Threading

Adapt the python code for jwz's threading algorithm, available at 
http://www.amk.ca/python/code/jwz. [This is the algorithm which was 
proposed for the imapext-thread Internet Draft (source - 
http://www.jwz.org/doc/threading.html)]

Also allow the user to manually thread by drag-and-drop where the 
algorithm gets it wrong

* Spam filtering

Support SpamAssassin headers. In this stage of development I think it 
would be best to outsource the spam filtering. If say a school server 
was to provide email it could use SpamAssassin. Using POP/IMAP with 
Gmail, spam is already filtered out by Gmail.

* Search, Filtering

Search functionality should be easy and helpful. Filters are applied at 
the time new email is processed.

Something very interesting would be to formalize a common grammar for 
searches, filters and 'smart tags'. Why? Having GUI's for 'advanced 
search', configuring filters, etc is clunky. I would like feedback on 
this. I personally don't think it is beyond kids to pick up a simple 
domain specific language :-)

Examples: I can search for "received:today", and also as easily create a 
smart tag called "today's email" using that string, or create a filter 
that applies tag "papa" to all emails I receive with 
"from:dad at smthn.org". The expressiveness could get a lot richer.

* Contacts

A simple address book would be implemented for address autocompletion. 
Can later be made more of a real address book, or could communicate with 
a (future?) contacts activity.

* UI

I don't have any mockups yet but I will have some time soon to work on 
them. I am happy to have the help of a student of Information and 
Digital Design with SVG icons and usability suggestions - he happens to 
be my brother so he would be there for me during the summer!

Availability
============

I can commit to spending at least 7 hours on this project every day 
through the summer. Communication with my mentor will not be a problem 
even if we are in very different timezones because I am flexible in that 
regard ;-) I'd be happy to be working on this activity beyond the SOC 
period as well.

Background, References
======================

I agree with most of the ideas presented by a former OLPC intern at 
http://dev.laptop.org/git?p=users/jrus/email-spec;a=blob;f=email-spec.text;hb=HEAD, 
especially with regard to search, tags, threading, filtering, et al. I 
disagree with his suggestion for IMAP email that it be kept on server, 
since we are looking to enable disconnected operation and the default 
behavior should be that messages are downloaded.

I have looked at the Tinymail framework 
(http://wiki.laptop.org/go/Tinymail) and it doesn't seem ideal for what 
I'd like for this activity (email organized around tags not folders).

Motivation and a little about me
=================================

I am a 20 year old Linux geek :-) I don't like the fact that Sugar does 
not come with an email activity and I want to make it happen.

I study Computer Science at Jacobs University Bremen in Germany, an 
international university with students from over 80 countries. When I 
applied here in 2006, the application had a little section for 
'Something you find especially interesting or important'... I wrote 
about the One Laptop Per Child project and how much I found the project 
inspiring and how the technology that is going into the laptop excites 
me. So I would love the opportunity to contribute.

I started learning Python in December 2007 and I think I have come a 
long way in terms of my Python skills. I have familiarized myself with 
most of the Sugar code that is relevant to this activity and over the 
past few weeks I have been meddling with pygtk.

This will also be a learning project for me. I like to be proud of the 
code I write, so I look forward to collaboration and feedback in an open 
community. I am dedicated to developing a solid email activity which 
children can use and love.

I would appreciate a review of my proposal and of course mentorship :-)

Best,

Shikhar