Tinymail

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 efficiëntly. The connectivity with "a server" is only implemented to fill that local store with something meaningful. I think the original asker 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 quircks), 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. And 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 are 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

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). 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 :-)

Tinymail itself isn't a service but a library. It however doesn't block you, at all, to develop a 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%.

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

Using the Python bindings

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