Re: [Evolution-hackers] Heads Up: More Camel API breakage in 2.31

2010-07-13 Thread Christian Hilberg
Hi, On Thursday 08 July 2010 Matthew Barnes wrote: I finally finished converting Camel's error handling code to GError. CamelException is no more. Is there a sensible way how we could deal with CamelException in our evolution-kolab plugin, which will be developed against 2.30? This is, can

Re: [Evolution-hackers] Heads Up: More Camel API breakage in 2.31

2010-07-13 Thread Matthew Barnes
On Tue, 2010-07-13 at 18:50 +0200, Christian Hilberg wrote: Is there a sensible way how we could deal with CamelException in our evolution-kolab plugin, which will be developed against 2.30? This is, can CamelException be wrapped in a way which will ease up the transition to GError, once

Re: [Evolution-hackers] Heads Up: More Camel API breakage in 2.31

2010-07-13 Thread Christian Hilberg
On Tuesday 13 July 2010 Matthew Barnes wrote: On Tue, 2010-07-13 at 18:50 +0200, Christian Hilberg wrote: Is there a sensible way how we could deal with CamelException in our evolution-kolab plugin, which will be developed against 2.30? This is, can CamelException be wrapped in a way which

Re: [Evolution-hackers] Heads Up: More Camel API breakage in 2.31

2010-07-11 Thread David Woodhouse
On Thu, 2010-07-08 at 11:58 -0400, Matthew Barnes wrote: I finally finished converting Camel's error handling code to GError. CamelException is no more. I plan to push this later today after a bit more testing. It will debut in 2.31.5 along with another libcamel soname increment. I note

Re: [Evolution-hackers] Heads Up: More Camel API breakage in 2.31

2010-07-11 Thread Matthew Barnes
On Sun, 2010-07-11 at 13:08 +0100, David Woodhouse wrote: I note that in some places you've elected not to propagate the error pointer. For example in imapx_parse_status_info(): -imapx_parse_status_info (struct _CamelIMAPXStream *is, CamelException *ex) +imapx_parse_status_info (struct