This required some reworking of assumptions I made early on when I first
wrote ESourceConfig, before I thought up the whole "collection" concept.
Not all ESourceConfigBackends will use a fixed parent UID, specifically
collection backends. In fact we may use multiple instances of the same
ESourceConfigBackend subclass if, for example, a user has two different
Exchange Web Services accounts configured. We would need to show both
EWS account (or "collection") names in the "Type" combo box.
For the moment collection-based ESourceConfigBackends are not listed
when creating a new calendar or address book since we lack support for
creating new resources on a remote server. A D-Bus interface for that
is in the works.
ECalSourceConfig drags in no additional dependencies, and although we do
publish a libevolution-calendar.so, this keeps all the ESource config UI
in one place so it can more easily be moved to Evolution-Data-Server.
EBookSourceConfig drags in no additional dependencies, and allows us to
delay publishing a libevolution-addressbook.so since 3rd party packages
will need to subclass EBookSourceConfig.
The address book source code will need to be flattened into a single
library before we could publish a libevolution-addressbook.so anyway.
That would be a good thing to do regardless -- Evolution has way too
many internal libraries -- but it's out of scope at the moment.
All mail-parsing and formatting code has been moved to em-format.
Parsing is handeled by EMailParser class, formatting by EMailFormatter.
Both classes have registry which hold extensions - simple classes
that do actual parsing and formatting. Each supported mime-type
has it's own parser and formatter extension class.
This splits the giant EMailRequest to individual EFileRequest, EStockRequest, EHTTPRequest and EMailRequest,
making the first two available globally from e-utils, the othe two are loaded only with mailer,
since no other component uses them.
