Talk:Tinymail

Tinymail is too fat

Tinymail supports SMTP, POP, IMAP and local message stores like mbox, mh, spool and Maildir. Tinymail also has its own local format.

--> You can of course pick which components you will compile. if you don't need SMTP and POP, you don't have to compile that

This is way too much for OLPC.

To begin with, the OLPC only needs one message store format which should be shared with all applications which use a message store.

--> You can pick that (and not compile the other formats). So that isn't a problem.

Given that the 2B1 runs a multitasking OS, it would be best for this message store to be something that can handle multiple processes accessing it at once. If file locking (or record locking) is too complex, the the message store should be owned by a simple daemon which serves all applications.

--> Tinymail can easily be used to play the role of a service (remote proxy pattern can be used for this). In fact I have already started some experiments that turn tinymail into a little service for E-mails. It worked but I don't yet see a good reason to push this path all the way. It didn't really caused any changes to the current tinymail infrastructure. So such a service can be developed on top of tinymail, rather than inside of tinymail (this is the purpose of tinymail, to ease building your solution on top of it)

Then, the question of network protocols comes to bear. There is not much point in supporting POP and SMTP and IMAP. IMAP itself might make sense, especially if it is extended to have a SEND operation,

--> Support for the SEND operation can certainly be done

but the fact still remains that the 2B1 will not have access to a traditional server infrastructure.

--> fetchmail the messages into a mbox or Maildir, and/or transfer them over XMPP

The concept of having an application that allows one to manage their received messages archive does make sense, but it needs to be better integrated with the OLPC concepts of networking which means a mesh network, built-in instant messaging and no servers.

activity version?

Has anyone tried to make an activity out of this? Sj talk 00:39, 11 August 2007 (EDT)

I'm looking into it. I've got tinymail downloaded and built for OLPC with python bindings. I am just starting to try to grok this - since it is made to serve many different purposes, only some of which I know, it is not transparent for me. So I could be wrong but here's what I think I'm gonna have to do: the tinymail-python-test script is built for a non-OLPC (Gnome?) datastore for accounts, so move it to TnyAccountStore. The build puts everything in the /opt directory, but activities are not supposed to have dependencies - move it all into the activity directory and get it working from there. (The comment "note: You can also use jhbuild. It's in the build files of sugar" seems to me to be incredible, though I haven't checked yet. Why would something that is nowhere near adapted for OLPC needs be in the jhbuild, when there is no indication in the Sugar spec of anything inside Sugar that would need any of these functions? Is this really planned as a common library for all devices? I can imagine an argument that this might be a good idea - but the first step is to have the argument or else its just bloat.) Then hack enough to make this usable, at a minimum provide some sort of account settings dialogue. As other discussion makes clear, that would still leave this as something inappropriate for the OLPC use case, because it would be server-dependent and not even have a persistent local datastore. This is just Sugar practice for me, though, so any further work is something I would not do, no matter how "trivial" it is to build on this framework. Homunq 01:27, 6 January 2008 (EST)