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.
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.
