Tinymail & Camel

Wow, it looks like I’m taking that TinyMail thingy serious. It’s the second evening in a row that I’m working on it. That’s a good sign!

Probably because I’m learning (learned and now enjoying) how to use the GTypeInterface stuff of GObject and Camel with it.

I’ll guide my blog readers through to idea. Note that all subversion URL’s might change as the subversion repository is just a temporary one.

The library libtinymail is a small abstract library that defines all types as interfaces and adds some proxy classes. It defines types like “account”, “message”, “body”, “header”, “folder”, “attachment” and the simple relations between these types. It also contains a few proxy classes which might get moved to the implementation library. This depends on how I’ll design my factory. If done fully correctly, I won’t need to depend the proxy classes on the implementation: think abstract factory technique. But I’ll see how far I’ll get.

I’m planning to use the proxy technique like how I used it in the treeview demo of last week, a lot. The experiment will be whether or not camel can cope with a concept that utilises the proxy technique. So far I haven’t found anything in the camel API that tells me that it won’t work. I’m hoping to speak the authors of camel about this sooner or later. NotZed, of you catch me on IRC or wherever: ping me? :-p

The library libtinymail-camel implements these types using Camel. It’s extremely unfinished, but the implementation for the type “account” shows what I mean. I’m not yet testing with the disksummary branch, but if the camel API doesn’t change a lot, the transition to that shouldn’t be difficult, right? My plan is to eventually only depend on that disksummary branch.

So far I haven’t found any reason why camel would be a lot less resource friendly compared to other imap4/pop3/smtp libraries. So for now I’m convinced that camel is a good candidate for mobile devices. And it comes with additional support for many stores and transports. It would, perhaps, be better if it wouldn’t be bundled with e-d-s. I don’t really understand why the evolution team didn’t simply make camel a separate package and let e-d-s depend on it. Rather than putting camel in a e-d-s subdirectory and cut-and-paste it’s build environment into the build environment of e-d-s. Harish, if you catch me on IRC .. please explain :-p?!

Note that the application itself will at this moment not do much useful for a normal user. It’s still to early. Developers, however, might be interested.