There are two major components involved the operation of Evolution, the client and the data server. The client, called "Evolution", is responsible for what the user sees on the screen. The data server, called "Evolution Data Server" is responsible for managing calendar and addressbook information.
The Evolution Data Server resides in the evolution-data-server Git module or the evolution-data-server package and is logically separated into client libraries and the backend implementations.
There are currently client libraries for addressbooks and calendars (calendars in this case referring to events and tasks), although this does not preclude the addition of other major types of data stores. The client libraries use CORBA (via bonobo) to communicate with the backends, but the communications layer is hidden from the user.
A backend implementation is divided into two parts, the corba pieces which handle incoming requests and outgoing responses and the pluggable C backends which do most of the work communicating with the storage mechanism. Both these pieces reside in a separate process to handle multiple clients properly. The corba piece is asynchronous, the calls are made "oneway" and the responses are sent "oneway". The pluggable C backends register themselves with the corba piece as a handler for various protocol types (and in the case of the calendar iCalendar object types) and when the corba piece gets a request for a calendar or addressbook it instantiates an appropriate C backend. The backends are asynchronous in nature, however to simplify the building of a backend you can subclass the synchronous backend class and implement it instead.
Evolution integrates calendar, addressbook and mail into a single user interface. Each of these pieces is implemented as a separate Bonobo component and is embedded into the main UI which is called the Evolution shell.
Each Evolution component has to implement a canonical Evolution::Component CORBA interface; when the shell starts up it queries Bonobo Activation asking for a list of all the Bonobo components that support that interfaces, activates them, and embeds them.
Camel is A Mail acEss Library.
True indeed, however Camel doesn't really stand for anything like that. It's just a short catchy name.
Camel resides in the camel directory of the evolution-data-server Git module. It is a very complete mail user agent library for internet mail access, sending and processing, loosely based on JavaMail. It totals nearly 100KLOC of "Pure C".
Conceptually Camel contains two main parts, a library of email and MIME related utilities, and an API and set of implementations for mail storage and retrieval. Although these are integrated into the one library, with implementations provided using a simple plugin system.
Like JavaMail it works via a synchronous multi-threading api. Because of this Camel uses its own object system, historically since GtkObject didn't provide any multithread capability, and it continues to because it has evolved features not present in GObject that greatly simplify multithreaded programming. Camel Objects are lighter weight and also provide thread-safe event handling in an efficient manner.
At its heart Camel merely implements RFC's, many of them. An example of some of the RFC's it implements or references:
But as well as implementing RFC's it provides a consistent high-level and generally high performance abstraction for working with mail folders and messages. Although it provides no direct display mechisms it provides many utilities and mechanisms to support the MUA.