Re: [Evolution-hackers] Rethinking Camel settings

[Matthew Barnes <mbarnes redhat com>]

On Thu, 2011-06-09 at 13:07 -0400, Matthew Barnes wrote: 
> I'm going to do the URL param to GObject property conversion in the
> master branch prior to merging the account-mgmt branch.  That will lay
> the groundwork for an smooth migration to key files when the time comes.

This is in master now for inclusion in Evolution 3.1.90.

TL;DR version: If you notice any Camel providers suddenly not working or
account editor settings not sticking, please file bugs.


The changes introduce a new class hierarchy in Camel rooted in a class
called CamelSettings.  CamelSettings and its child classes are nothing
more than GObject property containers.  This is now how Camel obtains
settings -- no longer through CamelURL parameters.

The class hierarchy of CamelSettings mimics that of CamelService.  That
is, each new CamelSettings subclass adds more GObject properties that
the corresponding CamelService subclass needs in order to operate.

Take IMAPX for example.  The service and settings class hierarchies have
a one-to-one mapping:

  CamelService                       CamelSettings
   |                                  |
   +-- CamelStore                     +-- CamelStoreSettings
        |                                  |
        +-- CamelOfflineStore              +-- CamelOfflineSettings
             |                                  |
             +-- CamelIMAPXStore                +-- CamelIMAPXSettings


Each CamelService instance owns its CamelSettings instance, accessible
as a GObject property or through camel_service_get_settings().

The CamelService creates its own CamelSettings instance automatically.
How does it know which type to create?  The CamelServiceClass struct has
a new member:

  struct _CamelServiceClass {
       ...

       GType settings_type;

       ...
  };

So each CamelService subclass must override this member if it defines
its own CamelSettings subclass.  CamelIMAPXStore, for example, does this
in its class_init() function:

  service_class = CAMEL_SERVICE_CLASS (class);
  service_class->settings_type = CAMEL_TYPE_IMAPX_SETTINGS;


For Evolution 3.2 we will continue storing these settings as strings
stuffed into URL parameters stuffed into XML blobs stuffed into GConf
keys.  To that end, there's a couple new TEMPORARY functions in Camel:

  void   camel_settings_load_from_url (CamelSettings *settings,
                                       CamelURL *url);

  void   camel_settings_save_to_url   (CamelSettings *settings,
                                       CamelURL *url);

Should be self-explanatory.  The functions know how to convert all
fundamental GTypes to strings and back, including enums.  Once we move
to key-file based accounts, hopefully by 3.4, this will all go away and
we'll be binding mail account settings to ESourceExtensions.  Getting
that working is next on my agenda.

Again, if you notice regressions -- especially in the extension modules
(GroupWise, Exchange, MAPI) where settings handling is already quite
messy -- file bugs and I'll try to resolve it quickly.  There's tons of
opportunity for typos and stupid oversights with these changes.  Despite
my best efforts I expect I made a few mistakes.