Talk:Projects/xomail

I think your understanding of Tinymail is flawed. Tinymail is mostly a set of back-end tools for constructing a front-end, not really a working client. The default client probably would work on Sugar, but to my knowledge no-one has done the work to install it and get it running (significantly, the compile options for "OLPC" and those for include-python-bindings are separate, which makes me wonder what "OLPC" means); thus it would be stretching the truth to call it "working". I have never programmed an email client, but I would imagine that, between the pain of learning to use a toolkit which already has python bindings (tinymail) and the pain of making a compatible email client from scratch, you'd probably be better off with the former. Email has been around for decades and the important protocols are definitely more byzantine than they should be. And yes, just put it in whatever box tinymail gives you, all flat, and do the index of tags yourself.

Certainly, it would be worth evaluating tinymail as opposed to python's standard libraries.

But feel free to ignore me, that is just my opinion.

Homunq 17:15, 1 April 2008 (EDT)

Hi Homunq, thanks for the feedback. No, actually, I do know that Tinymail is only a framework - in 'Background' I meant to refer more to the demo client. I will clarify the wording on the page. :-) An alternative user interface is definitely possible. Let me explain my reasoning for not really considering Tinymail. I think it's overkill. Really! Downloading all email from a POP/IMAP connection can be done in not many lines of code with Python. MIME parsing quite easy as well. And using Tinymail for just storage in mbox/maildir/mh does not make sense. Database storage is also less pain and makes more sense for my goals for this activity though it has to be done right. Shikhar 05:54, 2 April 2008 (EDT)

After some research I see your point :-) I have adpated my proposal for reliance on Tinymail. Shikhar 16:19, 6 April 2008 (EDT)

By PhilipVanHoof (Tinymail developer)

I would like to point out that during the following weeks I will be implementing support for Modest in tracker. Modest is an E-mail client based on Tinymail. Therefore it uses Tinymail's storage format for its caching. This cache is what tracker is going to be using for scanning/indexing the E-mails. Tracker puts the index into an SQLite database too.

Either you could reuse some of that code, you could develop into Tinymail a method to push index data into an SQLite, or OLPC could start using something like tracker. Note that if you are planning to implement a method into Tinymail to push index data (upon retrieval of messages, for example) into SQLite, that we (The Tinymail project developers) will prefer a generic or pluggable way. This way we could target things like tracker, the SQLite that is to be used on OLPC, Beagle and other kinds of search infrastructure too.

The preferred methodology for developing this is discussing this with us on IRC and on the mailing list, making a page on Tinymail's Trac wiki pages that describe your plans and then just implementing it. Sending one or more patches to the mailing list, etc etc. In case my mentor application for this activity gets accepted, I will of course as mentor guide you through all this.

Spam and Security

I strongly believe that you must address the spam problem. I don't want my daughter (or other kids) receiving even a thousandth of the crap I receive (and I use SpamAssassin). We have DansGuardian for web access. We must have something for email too.

Why can't we GPG sign all email by default? Jpritikin 22:52, 28 April 2008 (EDT)

I agree it is something that should be taken care of, however... as of now this email client does not exist in code, and I consider it my task this summer to get it into being, which will be quite an undertaking in itself; so I don't know if I'll be able to address spam filtering. Same goes for GPG signing outgoing messages by default. Once the activity exists, it won't be so hard to think of implementing these features. Shikhar 15:43, 29 April 2008 (EDT)

It's OK to go through this in stages, as you point out, however do please make sure this is not distributed to kids until suitable filters and tools are in place to keep their use safe, force it to be safe if need be - they probably could override any safety you build by simply signing up with Gmail if that is what they want, but a specific Sugar email client should be safe, by design and by default. Yamaplos 10:40, 27 May 2008 (EDT)

libtinymail-camel is from Evolution -- run away!

Evolution is well known for corrupting itself and for mangling email. Consider libtinymail-camel to be tainted by association or worse.

You particularly need to avoid any Evolution code that has anything to do with:

• the indexing and datastore
• editing and formatting

Dreadful bugs have persisted for many many years.

AlbertCahalan 02:10, 30 April 2008 (EDT)

libtinymail-camel will be used for email transport, MIME handling and maildir storage. Sorry, but I don't know of anything better than Tinymail for the purpose of this client. I had the Python libraries in mind earlier but they don't seem to be a good choice from the perspective of having been used in actual email clients. Shikhar 21:48, 2 May 2008 (EDT)

Teachers and an email client

I see the need for an email client a major priority for teachers, though it is for kids for the same reason, so they can collaborate with others beyond their schools. My views on this, http://www.olpcnews.com/use_cases/community/olpc_sur_grassroots.html Teachers working off their XOs depend on Gmail, they tend to prefer fewer emails. The list has ground to a halt since I put all the Gmail users into digest mode, which was requested by several list members, since the first week meant over 80 emails. Digest kills quick answers, and thus slows down an active list. Yamaplos 10:46, 27 May 2008 (EDT)