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
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 bug
On Mon, 2011-06-13 at 11:05 -0400, Matthew Barnes wrote:
>
>
> That's definitely something to revisit. I'd love to kill off those
> EPlugins. For the time being, though, I have to limit my scope since
> I'm trying to finish off my account-mgmt branch as fast as possible.
Understood.
> If you
On Mon, 2011-06-13 at 15:38 +0100, David Woodhouse wrote:
> But for the 'Receiving E-mail' tab, it's much more limited. The only
> control we have over that is the flags like CAMEL_URL_ALLOW_USER,
> CAMEL_URL_ALLOW_AUTH, CAMEL_URL_HIDDEN_HOST, etc.
>
> Could we make that more versatile, so that t
While we're looking at this, it might be an opportunity to get rid of
the UI plugins that the MAPI/GW/EWS/ActiveSync backends currently need.
For the 'Receiving Options' tab in the config, we have a
backend-provided list of options of various types, which is nice and
versatile.
But for the 'Recei
On Fri, 2011-06-10 at 23:07 +0530, Srinivasa Ragavan wrote:
> 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 f
Hi Matthew,
On Thu, Jun 9, 2011 at 10:37 PM, 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 UR
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 reas