[Evolution-hackers] Rethinking Camel settings

[Matthew Barnes <mbarnes redhat com>]

I'm at the point now with the account-mgmt branch where I have to deal
with the settings that trickle down into the various Camel providers.
The way the settings are managed now is to embed them into the Camel
service's URL string as a list of named parameters.  This is suboptimal
for the same reasons as the free-form ESource "property" dictionary:

  - All settings have to be manually converted to/from a string, even if
    it's a numeric or boolean value.  This is more of a nuisance than a
    blocker.

  - No way to query all available settings in a given CamelService
    instance, since some parameters may be omitted from the URL string.

  - No way to query the default values for these settings, which is
    important for things like the mail account editor.  Assuming FALSE
    or NULL or 0 in the absence of a parameter isn't always correct.

  - No nice way to push change notifications for these settings down
    to Camel.  In most cases an app restart is required.  That may be
    unavoidable for some settings, but we can do better overall.

So I'll be doing away with these free-form URL parameters and converting
them to GObject properties in the various CamelService subclasses, which
addresses all the shortcomings listed above.

Such properties will be tagged with a custom GParamFlag identifying it
as a setting, so it's easy to distinguish setting properties from normal
properties.  I used a similar approach in the new ESource API and it
worked out well.

For now we'll still stuff Camel settings into the URL string that gets
stored in the GConf XML blob, but we'll handle the packing and unpacking
of those URL parameters from Evolution.  Bear in mind the ultimate
destination for those setting values is key files, so Evolution will be
involved in the packing and unpacking of settings eventually anyway.
This is just a temporary stop-gap.

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.