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.
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.
Answer
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 (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
Documentation about building
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