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
Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)
On Wed, 2010-08-04 at 12:50 +0200, Christian Hilberg wrote: Using the Camel.HttpStream should do the trick - is that correct? I've seen the Camel.HttpStream being used within Anjal (file em-format-mail.c). Is this Camel HTTP part being used somewhere else as well (to be used as another reference)? You would be much better off using libsoup. Camel.HttpStream is only used to retrieve remote images and such for HTML mail. I plan to kill that class as soon as we move to WebKit/GTK+ for HTML rendering. ___ 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] evolution-kolab: Camel.HttpStream in the wild (?)
Hi Matthew, thanks for the prompt reply. On Wednesday, 04 August 2010 Matthew Barnes wrote: On Wed, 2010-08-04 at 12:50 +0200, Christian Hilberg wrote: Using the Camel.HttpStream should do the trick - is that correct? I've seen the Camel.HttpStream being used within Anjal (file em-format-mail.c). Is this Camel HTTP part being used somewhere else as well (to be used as another reference)? You would be much better off using libsoup. Does libsoup make use of NSS (just the newbie's uninitiated question)? Camel.HttpStream is only used to retrieve remote images and such for HTML mail. I plan to kill that class as soon as we move to WebKit/GTK+ for HTML rendering. Hey, thanks for that hint! :-) Maybe it would be wise to mark such classes as deprecated/removal candidate or something in the docs. (Bye)^2, 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] evolution-kolab: Camel.HttpStream in the wild (?)
On Wed, 2010-08-04 at 13:28 +0200, Christian Hilberg wrote: Does libsoup make use of NSS (just the newbie's uninitiated question)? It uses GnuTLS for transport layer security. http://www.gnu.org/software/gnutls/ Hey, thanks for that hint! :-) Maybe it would be wise to mark such classes as deprecated/removal candidate or something in the docs. You're right, I'll do that. ___ 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] evolution-kolab: Camel.HttpStream in the wild (?)
Hi there, On Wednesday 04 August 2010 Matthew Barnes wrote: On Wed, 2010-08-04 at 13:28 +0200, Christian Hilberg wrote: Does libsoup make use of NSS (just the newbie's uninitiated question)? It uses GnuTLS for transport layer security. http://www.gnu.org/software/gnutls/ Is there any good alternative to using libsoup which makes use of NSS? We're pretty much depending on the (mostly) working NSS infrastructure for PKCS #11 and token handling for certificate based client auth. From what I've read I get the impression that GnuTLS' PKCS #11 implementation is still rather experimental (true?), so we would (a) step on even more brittle ground (b) have another lib which we potentially need to configure for cert token use (which, when incompatible with parallel NSS use, probably is a no-go) when implementing/configuring token access for client cert retrieval. Any hints on how to handle this situation? 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] evolution-kolab: Camel.HttpStream in the wild (?)
On Wed, 2010-08-04 at 16:03 +0200, Christian Hilberg wrote: Is there any good alternative to using libsoup which makes use of NSS? We're pretty much depending on the (mostly) working NSS infrastructure for PKCS #11 and token handling for certificate based client auth. That I don't know. You might want to ask the libsoup maintainer, Dan Winship (d...@gnome.org). I will say libsoup has positioned itself as -the- HTTP client/server library for GNOME. Quite a lot of desktop infrastructure is already tied into libsoup, including other parts of Evolution and WebKit/GTK+, so I think you'll be hard pressed to find a better alternative. ___ 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] evolution-kolab: Camel.HttpStream in the wild (?)
Hi Matthew, On Wednesday, 04 August 2010, Matthew Barnes wrote: On Wed, 2010-08-04 at 16:03 +0200, Christian Hilberg wrote: Is there any good alternative to using libsoup which makes use of NSS? We're pretty much depending on the (mostly) working NSS infrastructure for PKCS #11 and token handling for certificate based client auth. That I don't know. You might want to ask the libsoup maintainer, Dan Winship (d...@gnome.org). [x] done. I've posted to the libsoup list, see [1]. Maybe we can dig up something useful there. Thanks and best regards, Christian [1] http://mail.gnome.org/archives/libsoup-list/2010-August/msg0.html -- 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
