Re: [Evolution-hackers] Rethinking Camel settings

[Matthew Barnes <mbarnes redhat com>]

Just a heads up that I just about have this work ready to merge.  I'll
wait and do it Monday after the 3.1.5 release since there's likely to be
some regressions (tons of little details to get wrong with this).

I realize it's getting late in the devel cycle, but I do want this in
for 3.2 so the bugs can get shaken out quickly and I can proceed with
integrating it with the new ESource API on the account-mgmt branch.

More details about the implementation when it lands.  It wound up being
slightly different than what I described below.


On Thu, 2011-06-09 at 13:07 -0400, Matthew Barnes wrote: 
> 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.
> 
> 
> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers