GNOME Bugzilla – Bug 674310
Allow camel imapx provider to be subclassed
Last modified: 2013-09-14 16:55:49 UTC
Split the camel-imapx library and camel-provider so that it can be subclassed. Providers such as kolab, groupwise etc. can use imapx backend for mail, over-ride its behavior if necessary. Register a callback to hook into the untagged responses from the server so that the subclasses can implement extended features for imap.
Created attachment 212268 [details] [review] Registers a callback which would be called if token cannot be matched in imapx and allows subclassed imapx provider to handle the same.
Created attachment 212269 [details] [review] Split camel-imapx library and its provider, allow imapx camel libraries to be subclassed.
I didn't test it, but looks good. Only do not use hander , but handler in the first patch :) I'm CC'ing Christian, in case he would like to have more things exposed in public, though I guess you have this discussed already.
The code changes look fine, my only thought is maybe we should just move the subclassable parts of IMAPX into libcamel proper and forego the awkward "providers/imapx/provider" and separate shared library arrangement. IMAPX doesn't bring any extra dependencies (except maybe gperf), so it's not like it would add bloat to libcamel.
@mbarnes, fine with me. I have encountered another problem in implementing the derived imapx provider using these changes. It is w.r.t the CamelSettings. The g_object_bind_property_full used in account-editor looks for properties in a particular GObject type. Say if I want to add some settings on top of CamelIMAPXSettings and I derive CamelGwIMAPSettings->CamelIMAPXSettings, the properties from the parent IMAPX are not recognized. Warning such as below indicates it, "GLib-GObject-WARNING **: gbinding.c:860: The source object of type CamelGwImapSettings has no property called 'auth-mechanism'" I see two options, 1) Add some custom properties with names "custom-1", "custom-2" etc. and allow the derived provider to use that for adding settings on top of imapx or 2) Duplicate the camel-imapx-properties.[ch] and add props there.. I prefer 1) solution. Do you see any other solution here ?
Hi, on a very short note, I've been on leave last week and still am this week, but will look into this as soon as I'm back in the office. Promising thing! :-)
(In reply to comment #5) > Say if I want to add some settings on top of CamelIMAPXSettings and I derive > CamelGwIMAPSettings->CamelIMAPXSettings, the properties from the parent IMAPX > are not recognized. Warning such as below indicates it, > > "GLib-GObject-WARNING **: gbinding.c:860: The source object of type > CamelGwImapSettings has no property called 'auth-mechanism'" CamelServiceClass has a "GType settings_type" struct member which is used to instantiate the correct CamelSettings type for the service. camel_groupwise_store_class_init() sets this to CAMEL_TYPE_GROUPWISE_SETTINGS. That's probably where the problem lies. When subclassing CamelIMAPXStore, be sure to set the "settings_type" class member in your class_init() function to CAMEL_TYPE_GW_IMAP_SETTINGS or whatever it's called.
Created attachment 212660 [details] [review] attached the camel-gwimap-provider.c, camel-gwimap-store.[ch], camel-gwimap-settings.[ch] for you take a look.. @mbarnes have done exactly that.
http://git.gnome.org/browse/evolution-data-server/commit/?id=7d7a889699586c092750638ac89da080eacb0129 http://git.gnome.org/browse/evolution-data-server/commit/?id=374b718710740873db5d9ed326d1d640609ef155 Fixed the issue regarding camel-settings which was due to my typo. error. Pushed the fixes. Groupwise provider based on imapx for mails and soap for calendar/address-book. http://git.gnome.org/browse/evolution-groupwise/commit/?id=35c9f644541f2551000a8eed348bc7210e426723 http://git.gnome.org/browse/evolution-groupwise/commit/?id=2a0cb20d3354eb50aa7f99cfbe03f19f7389a93e