I started a new project called TinyMail named after my girlfriend (Tinne). The plan is to create an E-mail client designed for mobile devices like the Nokia 770. The chances of ever achieving finishing a usable tool are small to zero, but … I guess it’s fun. Which is why I started nevertheless.
What I did so far is creating interfaces (a lot like what I did with that TreeView demo of last week). At this moment, I’m basically preparing all the objects and interfaces.
If you’re interested, please contact me.
You can follow the developments and latest code in this temporary subversion repository. Sure is whatever-forge cooler and whateverer but heck, it’s just a temporary location anyway. And the chances of somebody joining early in the game are extremely small.
The idea is the make use of the proxy programming technique, use an existing library like camel in the implementations of the real subjects and attempt to be as correct as possible in terms of design pattern usage. So that basically means that probably every type will have an interface, and that I’m going to try using for-c-programmers crazy programming principles and techniques. I know this is more or less nuts if you use gobject (checkout the gtktreemodel and gtktreestore code if you want to know how to create and work with interfaces in gobject). So be it.
Here’s some pointers to interesting information:
- ETable, the header-view component for Evolution
- Camel, a generic messaging library being used by Evolution
- Some idea’s for maemo’s osso-email
- Sylpheed, a lightweight e-mail client
The libtinymail and libtinymailui are components that will sit in between for example a library like camel and the user interface. They will take care of the high level caching (making sure that only visible things are abusing the memory — i.e. the proxy technique –). A lot like the models that can be used with ETable.
Note that no, a compiled version of whatever is in the repository a.t.m. will not do anything useful at this moment. It’s way to early for that. I might finished it in a few hundred years. You can, of course, join and help me.
Hi there – I couldn’t figure out your e-mail address from that post I’m afraid, but I thought you might be interested in an address book application that I’ve written working for OpenedHand – http://www.soton.ac.uk/~cil103/2005/12/contacts.html
It’s targetted at embedded use (in particular, the 770) and it uses eds-dbus, our dbus-using port of evolution-data-server.
Its been on my to-do list to write a mail client for a while too, but quite busy at the moment… Hopefully Contacts will help out somehow :)
Hey Cwiis, it might be interesting to join efforts on this. If e-d-s already works, I assume also the camel library has been ported and tested. This is, of course, good news.
The most important part of the e-mail client is, of course, trying to reduce the amount of memory being used. When/if showing IMAP folders of more than 10.000 e-mail headers, you obviously don’t want all those headers to be somewhere in memory.
Only the visible ones. Which is something I showed with that treeview demo last week.
What I’m doing with this tinymail is trying to bring that concept to a usable library and set of reusable user interface components.
In such a way that the entire “tinymail” stuff becomes highly reusable. More or less a component library for creating e-mail client applications for mobile devices.
But … that’s just idea’s and concepts :-)
Isn’t libcamel too heavy ? well, libcamel can do quite anything, that’s right, but for a lightweight email client, maybe one can look at tiny imap/pop3 and smtp libraries.
For example, the email client Whisper of Syllable OS (fork of Atheos) uses a very small pop3 library and a very small smtp library. I also have a toy library supporting full pop3/SSL (and having an awful implementation :-).
— see:
http://www.liqwyd.com/downloads/
http://brouits.free.fr/libspopc/
Hey Ben,
Whether or not camel is to heavy is something to investigate. The nice thing about using e-d-s (and it’s then available camel libraries) is that a working integration with groupware suites like Microsoft Exchange, Hula and others comes for free.
Also a calendaring backend, like Cwiis mentioned, comes for free with e-d-s.
But I agree that if camel is to heavy (but I first want to check that, because I see no real reason in it’s design why it would be heavyer than another implementation), it shouldn’t be used.
I’m also planning to abstract such a library from the application itself in that libtinymail. So the .h files wont (or shouldn’t, or aren’t, or it’s planned that they wont) be affected by the chosen smtp/imap/pop3 implementation. The .c files of libtinymail, however, will.
However .. I’m not yet at that point. I’m of course highly interested in working together on this ;-). Hah! :-p
“I started a new project called TinyMail named after my girlfriend (Tinne). The plan is to create an E-mail client designed for mobile devices like the Nokia 770. The chances of ever achieving finishing a usable tool are small to zero, but … I guess it’s fun. Which is why I started nevertheless.”
This sounds familiar.
“I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.”