Hi Matthew,

On Thu, Jun 9, 2011 at 10:37 PM, Matthew Barnes <mbar...@redhat.com> 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.
>

Everything sound pretty sane to me. Looking forward to these changes
soon. I'd also love to see a updated doc about how things were and how
they are now (or atleast a doc about how things are now). I would move
the e-mail-factory from the 2.32 code base to 3.3 once you land all
these stuffs. I'm looking forward to merge the code in that timeframe.
Will help me a lot to refine the dbus apis.

Thanks,
-Srini.
_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to