Todays commit and status

Hi folks,

Store and Transport accounts
Today I committed some improvements for libtinymail* that addresses the
fact that there's some differences between STORE and TRANSPORT camel

I basically made "reconnect" a abstract method in the abstract
TnyAccount type of libtinymail-camel. You basically have to implement it
to be a real account-type. Both TnyStoreAccount and TnyTransportAccount
do implement it. I should, perhaps, put the function pointer in the
class structure, rather than the private structure. Feel free to correct
this if you would like to do that.

Common functionality for libtinymail-camel
I also introduced a tny-camel-common.c which implements some
functionality that's shared across tny-msg-header.c and
tny-transport-account.c (the converting of address strings to a
CamelInternetAddress instance).

Creating messages
I refactored the TnyMsgIface type in such a way that it now implements
TnyMsgMimePartIface. The Camel implementation implements it by
inheriting from the TnyMsgMimePart camel implementation type. It should
be possible to perform all mime-part actions on a message type.

I've succeeded in sending an e-mail while setting some headers like the
To, From and Subject right. I didn't yet succeed in writing a body to
the e-mail but I did succeed in correctly adding a mime-part to the

Probably some small mistake I made about the stream and mime part
things. Feel free to jump ship and help me a bit here, if you feel

You'll basically have to study Evolutions source code and try to find
out how to do it. Which is very fun. Promised!

I adapted the tny-test-anything test so that it reflects the changes
about how you need to use the TnyMsgIface type. You, for example, need
to set the content-type of the message instance using the mime-part API.

As a message (from now on) implements that API. You can say that a
message is a mime part that can contain other mime parts. Like it's

The API changes
These changes do, indeed, increase the size of one message instance. But
a message instance shouldn't be created very often. You typically work
with header instances (or header proxy instances) in for example the
summary view. As the tinymail demo ui shows you. You create a message
instance by asking the folder ... you give it the header instance (the
one that should be behind your selected row, and it can be a proxy
indeed) and the method will return you a fresh and new message instance
which you can then start using. That's the idea here.

Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]