Tinymail

A little video demo

This is a little video demo that demos the standard demo user interface of the tinymail framework on an actual OLPC device.

An alternate interface

TMut is a minimalistic client based on Tinymail.

Proposed summer project

Projects/xomail#Ideas - feedback sought!

The big question is

OLPC can't depend on server infrastructure

According to the website it supports IMAP, Exchange and NNTP. It can be used to send messages over SMTP.

Given that the OLPC is used in an environment where there are no servers running IMAP, NNTP or SMTP, what use is it?

If it included a built-in IMAP and SMTP server that would hold messages for relay when a suitable server comes in range, then it might be more useful. Read the Instant messaging challenges page to see what the issues and use-cases are.

Tinymail isn't about just the connectivity with the server

Tinymail's main purpose is using the offline cache efficiently. The connectivity with "a server" is only implemented to fill that local store with something meaningful. I think the original question confuses this a little bit: it's not really just about that connectivity. Support for a new service isn't really the big job at all (in fact, that is the easy part).

The hard part is parsing the MIME parts from those messages (and the format of this depends on the E-Mail client that has sent the message -> like Ms. Outlook and its quirks), efficiently loading a lot header information into a list (and a view for it), storing whatever the service gives you in that efficient-loadable format, stuff like that.

It seems the main problem addressed in this question is the most easy piece of code in the entire framework: fetching the damn messages into a local store. That's easy (especially if you can decide about that service). A lot existing tools can do that (fetchmail) in case you don't trust tinymail to do it for you.

Tinymail supports local formats too

The tinymail framework also supports local message stores like mbox, mh, spool and Maildir. Maildir is what Courier's imapd typically also uses. Tinymail also has its own local format.

The software that fetches or receives the messages can store them in such a mbox, spool, mh or Maildir on the device. Tinymail can access that (without needing a build-in IMAP service or extra process). You could also run a small IMAP service locally, but I fail to see the reason for that: tinymail can also use these local message stores, Maildir, mh, spool and mbox efficiently by itself.

The tool that receives these messages can be anything. As long as it writes the messages in the mbox, spool, mh or Maildir storage format (these are specified and standards). Whether that tool is going to be a small SMTP server or a plugin for the instant messaging infrastructure, doesn't matter.

A fetchmail-like tool

A small software that pulls messages from a nearby (suitable) server, i.e. one that is in range, and stores it on the local disk (for example using the Maildir or mbox format), sounds like a trivial task. You can, for example, reuse the existing fetchmail tool. If the Maildir, mh, spool nor mbox formats aren't suitable, it would be easy to create support for yet-another-such local-storage-format in tinymail.

Another possibility would be letting the instant messaging infrastructure pass the messages. Using some xsl you can transform typical Jabber messages to mbox or a Maildir. It would also be possible to support a new such format (i.e. one that stores Jabber messages on disk).

A service (somebody asked about simultanously accessing the E-mail data)

Tinymail can be used to develop a service that exports messages and functionality to access a local store. Another possibility (that looks like this, but certainly isn't the same) would be to run a small IMAP server locally and have tinymail libraries handle access with that local store individually.

The idea behind tinymail as a service is that the local cache is stored only once on the device (in stead of per E-mail client application). Turning off caching (because the IMAP runs locally anyway) is possible in tinymail, and also fixes this issue (keeping "the local IMAP server"-solution a possibility).

You can of course implement IMAP and MIME functionality in all client applications manually and run a local IMAP server. I wish you good luck with that :-) (it took me a year to do tinymail, and the Evolution Camel team at least another year to do the MIME parsing and IMAP connectivity correctly). You can also do your own custom service, and I also wish you good luck with that (lots of companies have tried it, with very mixed results and years of man hours).

Tinymail itself isn't a service but a library. It however doesn't block you, at all, to develop a small desktop service with it. One possibility would be the remote proxy pattern and letting (some of the) the proxy instances at the client implement the same interfaces which tinymail exports. This way developing a client that or uses the service or the tinymail library directly would be done in the exact same way. Even ABI compatible (just linking with the library directly, in stead of linking with a library that implements the types by passing D-BUS messages with a service).

Developing such a service in Python using D-BUS is going to be something that will take one experienced Python+D-BUS developer a day or two. Tinymail's Python bindings cover the API 100%.

Example such calls:

• "Give me all folders" in a TnyList as TnyFolder instances on the client (TnyList is Python binded with the standard Python list stuff)
• "Give me all new headers" as TnyHeader instances on the client
• "Give me the message for this header/uid" as a TnyMsg instance on the client
• "Delete this message", "Move this message to"

I have such an experimental service, in Python, running. Mine is, however, just a little 50-lines experiment to proof myself the concept. Python + its D-BUS bindings are cool for this because that way it automatically discovers the methods the (proxy) instance implements (it 'knows' about the interface). Making implementing AND using this concept really, really simple.

I presented a few solutions, but be creative

Be creative. What I gave here as possible solutions definitely aren't the only available ones. Creativity is what drives the OLPC project, right?

Information about tinymail

• Website
• API reference documentation
• Trac developers website
• Subversion source code repository

Documentation about building

• Building documentation

Building a tinymail suitable for OLPC

svn co https://svn.tinymail.org/svn/tinymail
cd tinymail/trunk
./autogen.sh --prefix=/opt/tinymail-olpc --with-platform=olpc --enable-python-bindings
make && make install

note: You can also use jhbuild. It's in the build files of sugar

Creating an account

This is for the TnyAccountStore implementation of the libtinymail-olpc platform implementation (Jul 31 2006). You can find it here

mkdir -p $HOME/.tinymail/accounts/

IMAP

vi $HOME/.tinymail/accounts/01

[tinymail]
type=store
proto=imap
hostname=IMAPSERVER
user=USERNAME
name=OLPC IMAP test

Maildir

vi $HOME/.tinymail/accounts/02

[tinymail]
type=store
proto=maildir
url_string=maildir:///home/user/.mail/Maildir
name=OLPC Maildir test

Python bindings

Information on the Tinymail python bindings can be found on the tinymail wiki. It is intended that Python bindings will eventually be released with Tinymail.

This example will use this Python demo application.

cd tests/python-demo/
export PYTHONPATH=/opt/tinymail-olpc/lib/python2.4/site-packages/tinymail-1.0
python tinymail-python-test.py