Exchange Mailer architecture
From Evolution
The current design of Exchange mailer is because it was not opensourced in 1.4. And exchange-storage was not linked against camel. But now this can be relooked at.
Here is the diagram which tries to explain the communication between the mail backend and camel stub.
Command channel:
It is used for sending requests to backend and reading it's responses For example, sending commands (requests) to create/delete/subscribe) folder etc. and also getting the mail messages.
camel_stub_send: send messages from camel to backend This flushes the command channel after every command, to flush the buffered data by CamelStubMarshal.
camel_stub_send_oneway: send messages from camel to backend without requiring the status. This channel is locked by 2 mutexes, one for reading and one for writing.
Sender always encodes the data and receiver decodes it. For exapmle, backend reads the data from server encodes and then sends it.
Status channel:
It is used for reading the async notifications from backend. Camel provider spawns a separate thread to listen to the status channel.
connection_handler(): This function is used to receive the messages in backednd and call other functions to handle them. It adds a refcount to every message received. Response to every request is sent using the calls mail_stub_return_ok() or mail_stub_return_error(). These calles are used to unref the refcount in mailstub and also these flush both the channels. mail_stub_push_changes() is used just to push the status channel. mail_stub_return_data() is used to retrun the status code over the status channel.
Handling Notifications from Server
Mailer listens to OBJECT_ADDED, OBJECT_REMOVED and OBJECT_MOVED notification every 30 seconds.
Favorite Mail folders: A camel provider can register as all folders only or subscribed-only. Exchange tries to do both to show both the personal folder hierarchy and favorite folder hierarchy.
