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
Re: [Evolution-hackers] GOA Integration (was: New 'eclient' branch in eds)
On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote: > On Thu, 2011-06-09 at 21:56 +0100, Philip Withnall wrote: > > I guess this involves updating the Google Contacts address book backend > > to use GOA's OAuth 1.0 magic. I've recently updated libgdata to be able > > to cope with OAuth, and I've got an (untested) patch to e-d-s to update > > it to use libgdata's shiny new authorisation API. Over the next few days > > I intend to test it properly and fix it up. > > > > I hope this fits in well with what you've been conscripted to do re. > > GOA. > > Having just started on it this week, so far I'm mostly just concerned > with keeping Evolution synchronized with any Google online accounts. > > But yeah, I was hoping libgdata would make things magically work for > address book authentication. And I think I have a handle on the mail > side -- just need to extend our CamelSASL framework to handle XOAUTH > from outside of Camel. libgdata's new API implements authentication/authorisation using a GDataAuthorizer interface[1]. At the moment, libgdata has implementations of this interface for ClientLogin (Google's old username/password auth system) and OAuth 1.0. The patch I've got for e-d-s converts the Google Contacts address book backend to use libgdata's ClientLogin authoriser to keep up with libgdata's rampant API breaks. What I've been discussing with davidz is the implementation of some sort of GnomeOnlineAccountsAuthorizer class (in e-d-s' Google Contacts backend?) which implements GDataAuthorizer and just sticks GOA's OAuth 1.0 tokens onto every request. This would work for Google Contacts. > Google Calendars have me stumped, however, since we defer to our > standard CalDAV backend which authenticates with stored passwords from > the keyring. I'm not sure how to slip in OAuth integration for this one > special case. Hmm. I guess either the standard CalDAV backend could be modified to use OAuth if the domain name matches “google.com” (or whatever); or the Google Calendar backend could be resurrected with special authentication code, but sharing the CalDAV code with the normal CalDAV backend. Philip [1]: http://git.gnome.org/browse/libgdata/tree/gdata/gdata-authorizer.h > I'm open to suggestions if you have any. signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
