Re: [Evolution-hackers] Rethinking Camel settings
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.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking Camel settings
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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking Camel settings
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 have some further thoughts on making that more versatile, I'd > suggest jotting down a few notes on a wiki page and then I can come back > to it later in the year. I assume such enhancements could also apply to > the 'Sending E-mail' tab, even if there's less need for that. My only thought would be to obsolete those plugins; anything they need, we'd want to support. On 'Sending E-mail', I would also like to be able to switch to SMTP instead of using MAPI/EWS for sending email. Exchange is *so* broken, and SMTP is often available... -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking Camel settings
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 the UI plugins are no longer > required? That would make things a lot cleaner, especially for > alternative UIs based on EDS — and would even allow those back ends to > be merged into EDS for real, rather than living in separate > repositories. 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. If you have some further thoughts on making that more versatile, I'd suggest jotting down a few notes on a wiki page and then I can come back to it later in the year. I assume such enhancements could also apply to the 'Sending E-mail' tab, even if there's less need for that. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking Camel settings
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 '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 the UI plugins are no longer required? That would make things a lot cleaner, especially for alternative UIs based on EDS — and would even allow those back ends to be merged into EDS for real, rather than living in separate repositories. -- dwmw2 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking Camel settings
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 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. That's a good point. I'll try to put together a migration guide in the Camel API docs, similar to those in the GTK+ docs. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking Camel settings
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 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
[Evolution-hackers] Rethinking Camel settings
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
