Re: [Evolution-hackers] Camel IMAPX RFC5464 compliance
Please don't drop me from Cc when replying to my messages. See http://david.woodhou.se/reply-to-list.html On Wed, 2010-08-18 at 10:30 +0200, Christian Hilberg wrote: Hi everyone, On Thursday 05 August 2010 David Woodhouse wrote: On Wed, 2010-08-04 at 12:22 +0200, Christian Hilberg wrote: Now, I would like to know how we should deal with the issue. We (the evolution-kolab developers) could patch the 2.30 version of IMAPX only to get things running. In this case, would our additions be pulled upstream? [...] I would strongly recommend that you do it in the development branch first, then we can backport it to gnome-2-30. I've been backporting most IMAPX changes from master to the 2.30 branch; I see no particular reason why we shouldn't backport METADATA support too, as long as you're careful not to add new user-visible strings that would need translation. Okay, let's say, we will patch upstream IMAPX to support RFC5464. The patch gets reviewed, and after being polished it will (hopefully :-) be accepted in upstream. How long do you think it would take you to backport such a patch to 2.30, assuming we heed to the aforementioned implementation recommendations? Just to clarify -- I would expect you to do the backport yourself. When I said I've been backporting most IMAPX changes from master to 2.30... that's because I'd been making most of them. I wasn't volunteering to backport *your* changes too. :) It shouldn't be that hard. Probably even less than a day -- I suspect Chen was a little pessimistic in his estimate. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ 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] Camel IMAPX RFC5464 compliance
Hi everyone, On Thursday 05 August 2010 David Woodhouse wrote: On Wed, 2010-08-04 at 12:22 +0200, Christian Hilberg wrote: Now, I would like to know how we should deal with the issue. We (the evolution-kolab developers) could patch the 2.30 version of IMAPX only to get things running. In this case, would our additions be pulled upstream? [...] I would strongly recommend that you do it in the development branch first, then we can backport it to gnome-2-30. I've been backporting most IMAPX changes from master to the 2.30 branch; I see no particular reason why we shouldn't backport METADATA support too, as long as you're careful not to add new user-visible strings that would need translation. Okay, let's say, we will patch upstream IMAPX to support RFC5464. The patch gets reviewed, and after being polished it will (hopefully :-) be accepted in upstream. How long do you think it would take you to backport such a patch to 2.30, assuming we heed to the aforementioned implementation recommendations? Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ 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] Camel IMAPX RFC5464 compliance
On Wed, 2010-08-18 at 10:30 +0200, Christian Hilberg wrote: Hi everyone, On Thursday 05 August 2010 David Woodhouse wrote: On Wed, 2010-08-04 at 12:22 +0200, Christian Hilberg wrote: Now, I would like to know how we should deal with the issue. We (the evolution-kolab developers) could patch the 2.30 version of IMAPX only to get things running. In this case, would our additions be pulled upstream? [...] I would strongly recommend that you do it in the development branch first, then we can backport it to gnome-2-30. I've been backporting most IMAPX changes from master to the 2.30 branch; I see no particular reason why we shouldn't backport METADATA support too, as long as you're careful not to add new user-visible strings that would need translation. Okay, let's say, we will patch upstream IMAPX to support RFC5464. The patch gets reviewed, and after being polished it will (hopefully :-) be accepted in upstream. How long do you think it would take you to backport such a patch to 2.30, assuming we heed to the aforementioned implementation recommendations? It should just take a day or two once its approved. You just need to keep in mind that its not possible to add string/UI changes in gnome-2-30 branch. I am assuming that string changes would not be need since you would just check for server capabilities and add the meta data.. - Chenthill. Best regards, Christian ___ 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] Camel IMAPX RFC5464 compliance
On Wed, 2010-08-04 at 12:22 +0200, Christian Hilberg wrote: Now, I would like to know how we should deal with the issue. We (the evolution-kolab developers) could patch the 2.30 version of IMAPX only to get things running. In this case, would our additions be pulled upstream? As an alternative, would anyone like to implement RFC5464 in the current upstream IMAPX so we could try and backport the changes into 2.30? I would strongly recommend that you do it in the development branch first, then we can backport it to gnome-2-30. I've been backporting most IMAPX changes from master to the 2.30 branch; I see no particular reason why we shouldn't backport METADATA support too, as long as you're careful not to add new user-visible strings that would need translation. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ 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] Camel IMAPX RFC5464 compliance
Hi again. On Monday 26 July 2010 Christian Hilberg wrote: while I suspect the answer will most likely be no, just to be sure I'd like to put the question here anyway (if only for the record): Does the Camel IMAPX implementation comply with RFC5464 The IMAP METADATA Extension [1] ? [...] [1] http://www.faqs.org/rfcs/rfc5464.html After taking a closer look at the IMAPX implementation (and since there was no veto here), it seems clear that the 2.30 IMAPX does not support the RFC5464 IMAP protocol extension. Now, we need this functionality in our evolution-kolab plugin to avoid ugly workarounds (like scanning all folder contents in order to find out the folder type) when working with Kolab IMAP (PIM) Folders. We could patch the IMAPX implementation to add RFC5464 functionality. This would mean that IMAPX needed to be extended by two new IMAP commands (SETMETADATA and GETMETADATA), and one new response (METADATA). The GETMETADATA command has two options, MAXSIZE and DEPTH. The METADATA response may carry values. For further details, please see RFC5464. In all, it does not seem to be overly complicated. However, apart from implementing the protocol extension itself, it would mean to also extend the IMAPX API. This should be possible to implement just as an extension to the existing API so we would not break anything, right? Now, I would like to know how we should deal with the issue. We (the evolution-kolab developers) could patch the 2.30 version of IMAPX only to get things running. In this case, would our additions be pulled upstream? As an alternative, would anyone like to implement RFC5464 in the current upstream IMAPX so we could try and backport the changes into 2.30? Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ 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
