I did some more work on tinymail this evening: I’ve been putting the infrastructure for sending mails into place. I made sure creating a message header, a mime part and a message is now possible. I refactored the account-type a little bit (there’s now a store-account and a transport-account). And I created a few unit tests that test the stream infrastructure (as this has to work if you want to create mime parts).
I’ve also been working on finishing the support for POP mailboxes. I adjusted the header type so that it supports folder types with support for summaries and without such support. I added a special case in the (now new) store-account camel implementation, as in camel POP accounts don’t handle folders like IMAP accounts (there’s only one real remote folder, the INBOX folder).
Hmm, if all the crap I just mentioned is working correctly, I might release some first version of the framework. Until then, don’t expect any API stability. Even after such a release it’s going to be likely that the API will change a lot.
Anyway, there’s some people (on IRC) who’ve been asking me questions like: why are you doing this?!.
The answer isn’t “to build a replacement for Evolution”. Nor would making it use libtinymail make the current implementation faster. Probably a little bit slower. The simple reality is that libtinymail would reduce the amount of features to an absolute minimum. It would improve memory usage. Probably a lot. But that isn’t an interesting conclusion as the evil eye of tinymail isn’t looking at Evolution. It sure looks like to much people are hoping it would start doing that. It wont. (It can’t, Evolution is multiple years of work for a single person)
That eye is looking only at the many mobile devices that don’t have a nice E-mail client at this moment. It’s not strictly focused at gtk+-capable such devices. It’s also not said that it’ll be camel-only. However, at this moment there’s no reason to switch that technology. I’m “using” camel because it supports many providers and because it has relatively small memory requirements.
Anyway, so why am I doing it personally? Because I started enjoying working on it? Because it’s a challenge? I can give you many reasons. Above all, I think .. reasons like “I want to show people how to do it”, “prove of concept”, “learning”, etcetera.
I’ve also been asked whether I’m planning to support message threading. I’m not planning it at this moment. Feel free to send me some analysis on whether the algorithm can be used with my “only load the header-info of visible rows” ideas. Probably not. On a mobile device, loading header-info of invisible rows isn’t a good idea when displaying large folders. I’ve been thinking about sorting when messages get received and storing the tree-index. Rather than sorting each time a folder is to be displayed. That way you can let the sorting (which basically means reading all header-info) happen on idle moments. Nevertheless would that consume device battery. So perhaps do it while the device is charging?
If you need a new laptop battery or any other kind, such as a digital camera battery, then you may want to recycle your batteries rather than just dispose of them in the trash. Besides, many of the components in a battery, especially large and complex laptop batteries, aren’t meant to be put into trash piles.
The thing is, desktop users are crying out for a simple mail application as well. The current situation (where Mozilla Thunderbird actually feels like a speedy and uncluttered alternative to Evolution) is pretty dire considering how well the rest of the modern Free desktop is doing.
This doesn’t even require message threading. It just requires as much functionality as a traditional webmail client with a faster response time. I know I’d use it.
– Chris
First of all, I totally a gree with Chris Cunningham in the previous comment. I am also a user waiting for some smaller, faster version of Evolution. Luckily you, and some others are partly realising that dream (Dates, Contacts and now Tinymail). It might not be the nr 1 purpose of tinymail, but it can certainly be used as a replacement for Evolution on the desktop.
Now a possible solution for the threaded-with-only-visible-rows: use a conversation-based view/method, like Gmail does. It is not as functional as real threaded listviews, but it can give part of the functionality.
Good luck Philip! You are doing great work.
On a mobile device, you don’t want large folders in the first place.
Every mobile client has options to the effect of limiting the stored mail to some recent time period.
OTOH, displaying threads may be unwieldy on a mobile device.
mzabaluev, there’s not a single reason why limiting the amount of messages is needed, for a mobile device. Except storage when using POP boxes (this isn’t a valid reason when using IMAP as storing the message-header on-disk cache of a folder of more than 100.000 headers is still very doable on most mobile devices).
The proxy design pattern, which I’ve been using, makes it possible to show such a IMAP folder (of more than 25.000 messages) using less than 2 MB of ram. By only ‘loading’ the header-info of the visible rows.
There’s techniques for displaying threaded messages on small screens. The reason why not to do it is because you need to ‘read’ all the header-info. That ‘reading’ is expensive for a mobile device. Those disk-seeks would probably consume a lot battery. A problem that can be solved by detecting whether or not the device is charging.
Also note that POP-boxes (using camel) can also support a feature like ‘only on-disk caching of the header-info’. So even for a POP box, it would be doable. But you’d need to leave the messages on server and stuff like that …. and that might not work with all POP servers.
michiels: Anyway, tinymail is not being designed for desktop usage. Maybe somebody will implement alternative techniques and implementations of my work that is more targetted at desktop usage. About message threading: you are, of course, welcome to implement and investigate the threading ideas you propose.