Re: [Evolution-hackers] [PATCH] evolution-ews: implement Exchange categories as evolution labels (read only)
On Mon, 2011-06-27 at 13:22 +0100, David Woodhouse wrote: > On Mon, 2011-05-23 at 16:55 +0400, James Bottomley wrote: > > > > I kid you not. > > > > You can see this just by going to your own outlook web server (when you > > highlight a message, you'll see an empty tall oblong, click and it will > > bring up the categories). > > > > Exchange allows arbitrary labels (like we do), but the default ones are > > Blue, Green, Orange, Purple, Red and Yellow. Evolution has label > > mappings for everything apart from Yellow. I figured we should map > > default to default. > > I don't really like mapping 'Red' to 'Important', etc. I was just doing a mapping of what seems to be intended. This is also what the imap camel plugin does (except it maps $label1 <-> important etc.) > Given that we support arbitrary labels on both sides, I think the best > solution is to synchronise the set of labels. If we see a label on an > Exchange message which isn't already known in Evolution, *add* it to > Evolution's list. And if we're trying to add a label to an Exchange item > which isn't already known on the Exchange side, add it there too. I don't think we can ... at least it's an invasive change. There doesn't seem to be a way to show arbitrary labels. The plugins have a label map, which is partly provider supplied and partly user supplied (if the provider allows user labels). If the imap server comes across a label it doesn't have a map for, it just ignores it ... This keeps biting me because I use a custom patch label in my mailboxes for my git workflow. When I move to a new machine, I always have a "WTF where are my patches" moment ... until I remember to add the label mapping. James ___ 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 30 June 2011 19:45, Matthew Barnes wrote: > Once I can verify that it actually works I'll see if Dan's interested, > although he did point me to librest, which is libsoup-based and provides > more complete OAuth support than my little hack. > > http://git.gnome.org/browse/librest/tree/rest > (can't find any online API docs for it) Oh, I should sort that out. librest has gtk-doc and almost reasonable coverage. > It's looking like GLib might get HMAC support soon too, so we could sign > tokens without liboauth's help. librest does HMAC too, if you fancy copy-and-pasting some crypto code. ;) I will pimp librest and say that if you have any questions about it, please ask. Ross ___ 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-30 at 18:34 +, Philip Withnall wrote: > That's a neat idea. Perhaps it would be worthwhile putting this in > libsoup proper so that we have a common place for OAuth implementations. > It does seem to be the right place. Once I can verify that it actually works I'll see if Dan's interested, although he did point me to librest, which is libsoup-based and provides more complete OAuth support than my little hack. http://git.gnome.org/browse/librest/tree/rest (can't find any online API docs for it) It's looking like GLib might get HMAC support soon too, so we could sign tokens without liboauth's help. https://bugzilla.gnome.org/show_bug.cgi?id=652480 > That's unfortunate. Google don't seem to really love the Calendar APIs > or CalDAV interface much. :-( I posted a question about it in their Calendar API forum. We'll see... http://code.google.com/apis/calendar/community/forum.html?place=topic%2Fgoogle-calendar-help-dataapi%2F1uyk2pk9yHI%2Fdiscussion ___ 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-30 at 13:45 -0400, Matthew Barnes wrote: > On Fri, 2011-06-10 at 17:02 +0100, Philip Withnall wrote: > > On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote: > > > 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. > > Just to follow up on this... > > I wrote a custom SoupAuth class for OAuth. Instead of calling > soup_auth_authenticate() on it, you would instead call a different > function that takes the consumer key, consumer secret, token and token > secret strings as parameters, which the GNOME Online Accounts API > provides. That's a neat idea. Perhaps it would be worthwhile putting this in libsoup proper so that we have a common place for OAuth implementations. It does seem to be the right place. > Turns out it was all for naught, because I later realized Google's > CalDAV interface currently only supports Basic HTTP authentication. > Haven't seen any indication that OAuth support is forthcoming. That's unfortunate. Google don't seem to really love the Calendar APIs or CalDAV interface much. :-( Philip > So that kinda sucks; users will still have to enter a password to access > the calendar even if they have a valid access token. But it does mean > GOA integration in Evolution is pretty much done for now and I can get > back to other priorities. I'll keep my little SoupAuth class around in > case the situation with Google's CalDAV interface changes. > > 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
Re: [Evolution-hackers] GOA Integration (was: New 'eclient' branch in eds)
On Fri, 2011-06-10 at 17:02 +0100, Philip Withnall wrote: > On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote: > > 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. Just to follow up on this... I wrote a custom SoupAuth class for OAuth. Instead of calling soup_auth_authenticate() on it, you would instead call a different function that takes the consumer key, consumer secret, token and token secret strings as parameters, which the GNOME Online Accounts API provides. Turns out it was all for naught, because I later realized Google's CalDAV interface currently only supports Basic HTTP authentication. Haven't seen any indication that OAuth support is forthcoming. So that kinda sucks; users will still have to enter a password to access the calendar even if they have a valid access token. But it does mean GOA integration in Evolution is pretty much done for now and I can get back to other priorities. I'll keep my little SoupAuth class around in case the situation with Google's CalDAV interface changes. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
