[Evolution-hackers] Evo and Kolab2 - a fresh attempt

2010-05-25 Thread Christian Hilberg
. It would be great to be pointed into the right directions here. Questions galore - any helpful input will be kindly appreciated. :) Best regards, Christian Hilberg -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen

Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt

2010-06-07 Thread Christian Hilberg
, Christian Hilberg wrote: We'll check that out with other Gnome projects. It may take some more research on the project itself before we know how to actually accomplish the testing stuff. My thoughts atm tend towards cunit/expect and/or the GLib testing framework. I think the consensus from

[Evolution-hackers] [evolution-kolab] Datastructures for calendar data

2010-06-24 Thread Christian Hilberg
Hi there, I'm trying to dig up the EDS data structure which is currently used to hold calendar data. Searching the sources (among others, evolution-mapi), I found ECalComponent being used as a toplevel data structure for calendar data. Regarding this data structure, I found:

[Evolution-hackers] [evolution-kolab] IMAPX and sync- vs. async-Backends

2010-06-29 Thread Christian Hilberg
Hi there, reading about the new IMAPX implementation used by Evo =2.30, I found it stated that Maybe if imapx had come up before, many backends such as groupwise, mapi etc. would have followed this design rather than a sync one. -- Chenthill in [1] Does this mean

[Evolution-hackers] Evo-Plugin Coding Style

2010-07-01 Thread Christian Hilberg
Hi all, searching evolution-hackers about Evolution coding style, I found http://projects.gnome.org/evolution/patch.shtml referenced as the coding style reference ;-) for Evolution. Is this document still fully valid so we may use it as style guide for our project? Are there any

Re: [Evolution-hackers] Evo-Plugin Coding Style

2010-07-01 Thread Christian Hilberg
On Thursday 01 Juli 2010 at 13:01:22 Matthew Barnes wrote: On Thu, 2010-07-01 at 11:43 +0200, Christian Hilberg wrote: searching evolution-hackers about Evolution coding style, I found http://projects.gnome.org/evolution/patch.shtml [...] That's still more or less valid. There's

Re: [Evolution-hackers] Evo-Plugin Coding Style

2010-07-01 Thread Christian Hilberg
On Thursday 01 Juli 2010 at 13:30:26 Tor Lillqvist wrote: style. patch.shtml talks about 8-space-tabs Just some nitpicking here: I hate it when people say loosely that tabs correspond to 8 spaces (or four, or whatever). For good reason. :-) Just quoted

Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt

2010-07-07 Thread Christian Hilberg
Hi Michael, On Wednesday 26 May 2010 at 12:18:04 Michael Meeks wrote: Hi Christian, [...] It'd be better really to develop vs. master - from a support, testing, future-proofing, and ease-of-use perspective. Presumably it is possible to get you commit access to the repository so you

[Evolution-hackers] evolution-kolab: Lifting the veil

2010-07-08 Thread Christian Hilberg
concepts) Christian Hilberg (kernel concepts) Hendrik Helwich (tarent) Umer Kayani (tarent) More resources may be allocated as needed. :) About the project The goal of the evolution-kolab project is to provide a plugin for Evo/EDS which will allow Evo users

[Evolution-hackers] evolution-kolab: local cache for offline-work

2010-07-08 Thread Christian Hilberg
Hi all, in evolution-kolab, we need to provide full offline capabilities for working with Kolab 2 groupware data in offline mode. Evo 2.30 has an offline mode which works for IMAP email. If I understood correctly, email handling resides within Evolution presently [1], not E-D-S. For our

Re: [Evolution-hackers] evolution-kolab: Lifting the veil

2010-07-08 Thread Christian Hilberg
Hi Michael, On Thursday 08 Juli 2010 at 17:01:36 Michael Meeks wrote: [...] On Thu, 2010-07-08 at 10:28 +0200, Christian Hilberg wrote: We will try to map as much of Kolab's functionality as possible onto Evolution whithout changing Evolution itself (other than providing a plugin

Re: [Evolution-hackers] evolution-kolab: Lifting the veil

2010-07-09 Thread Christian Hilberg
Hi there, On Thursday 08 July 2010 at 19:01:25 Matthew Barnes wrote: [...] Certainly aim for hosting your project on git.gnome.org, but I'd still prefer it be split into a separate evolution-kolab repository similar to evolution-exchange, evolution-mapi, and soon evolution-groupwise (I'm

Re: [Evolution-hackers] evolution-kolab: local cache for offline-work

2010-07-09 Thread Christian Hilberg
On Thursday 08 July 2010 at 15:50:19 Christian Hilberg wrote: Hi all, in evolution-kolab, we need to provide full offline capabilities for working with Kolab 2 groupware data in offline mode. Anything? Anyone? :-) Best regards, Christian -- kernel concepts GbRTel: +49-271

Re: [Evolution-hackers] evolution-kolab: local cache for offline-work

2010-07-09 Thread Christian Hilberg
On Friday 09 July 2010 at 18:01:53 chen wrote: [...] Let me try to summarize some pointers for calendar and you could do the same for address-book as well, + Create New ECalBackend for Kolab + Use the camel apis to fetch the calendar folder + Using the CamelFolder, get its contents. You

Re: [Evolution-hackers] evolution-kolab: local cache for offline-work

2010-07-09 Thread Christian Hilberg
Hi Chen, thank you very much for taking time to clarify things! Much appreciated. On Friday 09 July 2010 at 18:43:32 chen wrote: On Fri, 2010-07-09 at 18:25 +0200, Christian Hilberg wrote: * Does there exist any infrastructure in E-D-S which will help us creating a local email cache via

Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data

2010-07-13 Thread Christian Hilberg
Hi again, no ideas? Anything? 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.

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 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] [evolution-kolab] Datastructures for calendar data

2010-07-14 Thread Christian Hilberg
Hi there, On Wednesday 14 July 2010 Ross Burton wrote: On Wed, 2010-07-14 at 20:14 +0530, chen wrote: Though only subclass this if you can't handle the async nature of the ECalBackend API yourself. Whether you subclass ECalBackend or ECalBackenSync is a choice made by how the backend

[Evolution-hackers] evolution-kolab: on (Unit) testing again

2010-07-16 Thread Christian Hilberg
Hi all, regarding Unit-testing our plugin, we've settled on the GLib Testing framework and Unit tests written in C. Now, when doing integration testing, we will certainly try to automate a few things. Question is: does there exist a preferred scripting tool / language within the Evolution

[Evolution-hackers] evolution-kolab: Display of extended free-busy lists

2010-07-19 Thread Christian Hilberg
Hi all, within the evolution-kolab plugin, we would like to display extended free-busy information if some is available on the Kolab server. Extended f/b lists have some text attached to the busy information for any user within the same calendaring group. This feature is provided by the Kolab

[Evolution-hackers] evolution-kolab: using a TPM for SSL/TLS client certs

2010-07-20 Thread Christian Hilberg
Hi all, ...the story continues... As a part of our project, we need to support TPM hardware as certificate source for client-authentication against client-auth-enabled services. Within Kolab context, these are mainly IMAPS, SMTPS, LDAPS and HTTPS. The tpm-tools suite and openCryptoki will

[Evolution-hackers] evolution-kolab: hiding IMAP folders

2010-07-20 Thread Christian Hilberg
Hi all, ...still continuing... Kolab makes use of RFC5464 - The IMAP METADATA Extension IMAP folder annotations to differentiate between the various folder types which are handled by Kolab. Remember, anything (Email and PIM data) is stored as Email messages with XML attachments in IMAP

Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders

2010-07-20 Thread Christian Hilberg
On tuesday 20 July 2010 Christian Hilberg wrote: [...] From within Evolution, *only* the IMAP folder which is annotated Email ^^ the IMAP folders which are annotated, this is. Best regards, Christian -- kernel

Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders

2010-07-20 Thread Christian Hilberg
Hi there, thanks Milan for your reply. On Tuesday 20 Juli 2010 Milan Crha wrote: On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders

Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders

2010-07-20 Thread Christian Hilberg
Hi there, On Tuesday 20 July 2010 chen wrote: On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: [...] Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders

Re: [Evolution-hackers] evolution-kolab: Some design thoughts on Email handling

2010-07-23 Thread Christian Hilberg
Hi Milan, thanks for your explanations, though they undermine what little idea about Evolution design I thought I had... ;-) On Friday 23 July 2010 Milan Crha wrote: On Fri, 2010-07-23 at 10:43 +0200, Christian Hilberg wrote: We would need the possibility to define extra D-Bus communication

Re: [Evolution-hackers] Camel IMAPX RFC5464 compliance

2010-08-04 Thread Christian Hilberg
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

Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)

2010-08-04 Thread Christian Hilberg
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

Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)

2010-08-04 Thread Christian Hilberg
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

Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)

2010-08-04 Thread Christian Hilberg
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

Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)

2010-08-05 Thread Christian Hilberg
Hi again, On Wednesday 04 August 2010 Christian Hilberg wrote: 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

Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)

2010-08-06 Thread Christian Hilberg
Hi there, On Thursday 05 August 2010 Matthew Barnes wrote: On Thu, 2010-08-05 at 18:30 +0200, Christian Hilberg wrote: Result: While libsoup should build against the current GnuTLS lib (development version, 2.11.0), which has PKCS #11 support since a few weeks now, libsoup has

Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)

2010-08-06 Thread Christian Hilberg
Hi Stef, On Friday 06 August 2010 Stef Walter wrote: [...] FWIW, gnutls is working on PKCS#11 support. The first bits have been added and I've been working with the gnutls maintainers on some of the remaining parts. I believe libsoup will start using this in the near future. Yes, we've seen

[Evolution-hackers] evolution-kolab: working with multiple Camel.Provider instances

2010-08-06 Thread Christian Hilberg
Hi. In the backend code for our plugin, we will need to handle two IMAPX providers simultaneously, one for the address book backend and one for the calendar backend. Normally, there will be a single Camel.Session instance only. Will this be true in our case as well, when there are multiple

Re: [Evolution-hackers] Camel IMAPX RFC5464 compliance

2010-08-18 Thread Christian Hilberg
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

[Evolution-hackers] evolution-kolab: IMAPX RFC2086/RFC4314 (IMAP4 ACL) compliance

2010-08-25 Thread Christian Hilberg
Hi everyone, searching Evolution lists, docs and source, I found that supporting IMAP4 ACLs has been discussed now and then, but I could not deduce from what I've read that the IMAP/IMAPX providers actually do support ACLs. Support for IMAP ACLs would be very useful when dealing with a Kolab

Re: [Evolution-hackers] evolution-kolab: IMAPX RFC2086/RFC4314 (IMAP4 ACL) compliance

2010-08-26 Thread Christian Hilberg
On Wednesday 25 August 2010 David Woodhouse wrote: ∄ ACL support in imapx. Thanks for the information (though I was hoping for a different one :-). (Bye)^2, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen

[Evolution-hackers] evolution-kolab: Subclassing and extending IMAPX

2010-09-09 Thread Christian Hilberg
Hi everyone. After some time working on different places within our Plugin, I'm back to our IMAPX part. braindump We would like to use the IMAPX implementation for our backends as well as for the Evolution Email part when Kolab access is configured. Thing is, we cannot just use the plain

[Evolution-hackers] evolution-kolab: IMAPX licensing

2010-09-13 Thread Christian Hilberg
Hello again. While working through the IMAPX sources, I noticed that there are three kinds of licenses in the headers for the *.[hc] files of the IMAPX implementation: * GPLv2 * LGPLv2 * {nil} The COPYING file in the E-D-S toplevel directory states LGPLv2, this is what we checked initially.

Re: [Evolution-hackers] evolution-kolab: Subclassing and extending IMAPX

2010-09-15 Thread Christian Hilberg
Hi, On Thursday 09 September 2010 Christian Hilberg wrote: [...] ANNOTATEMORE and METADATA differ in the syntax they use and they have some minor semantic differences. [...] Just for your reference: RFC5464 - The IMAP METADATA Extension http://www.faqs.org/rfcs/rfc5464.html IMAP

Re: [Evolution-hackers] evolution-kolab: on (Unit) testing again

2010-09-16 Thread Christian Hilberg
Hi, On Friday 16 Juli 2010 Matthew Barnes wrote: On Fri, 2010-07-16 at 15:54 +0200, Christian Hilberg wrote: Within our project it has been brought up that POSIX shell scripts might be a good choice in order to keep a low profile depencency-wise. Personally, I would prefer a higher-level

[Evolution-hackers] evolution-kolab: public Git repo online

2010-09-17 Thread Christian Hilberg
Hi everyone. JFYKI: There is a public Git repo online now with some sources for the evolution-kolab plugin. If you like, check out http://sourceforge.net/projects/evolution-kolab/ The repo is not open for public commits, though. Please be aware that this code is very much pre-alpha and not at

Re: [Evolution-hackers] evolution-kolab: public Git repo online

2010-09-17 Thread Christian Hilberg
On Friday 17 September 2010 Christian Hilberg wrote: [...] There is a mailing list which should become acessible over the weekend. It's there now. (Bye)^2, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072

Re: [Evolution-hackers] Account management and keyrings

2011-01-20 Thread Christian Hilberg
Hi, On Thu 20 January 2011 Matthew Barnes wrote: On Thu, 2011-01-20 at 18:24 +0100, Milan Crha wrote: Nope, go for it. It may also fix an issue with BirthdayAnniversaries calendar, when using authenticated addressbook, as right now there is no easy way to ask for a stored password for that

Re: [Evolution-hackers] Evolution 2.28 obsolete?

2011-01-27 Thread Christian Hilberg
Hi Matt, On Thu 27 January 2011 Matt Davey wrote: I'm not sure this is the right list, as this is more of a policy question than a dev question. I recently logged a bug (#639970) that crops up every now and again for me, and it was closed as OBSOLETE because I raised it against Evolution

[Evolution-hackers] Backend requesting arbitrary user input from frontend

2011-03-23 Thread Christian Hilberg
Hi all. Part of the overall evolution-kolab project is to make it possible for Evolution (as a Kolab client) to use TPM [1] infrastructure. In short, it's all about certificate based client authentication, where clients can be forced to authenticate themselves against a server when

Re: [Evolution-hackers] Backend requesting arbitrary user input from frontend

2011-03-23 Thread Christian Hilberg
Hi again, Am Mittwoch 23 März 2011, um 18:03:32 schrieb Christian Hilberg: Hi all. [...] Maybe this is a more general thing than just having a backend requesting a user PIN. I can imagine other scenarios where a backend might need to request any user interaction, input, whatsoever, which

Re: [Evolution-hackers] Backend requesting arbitrary user input from frontend

2011-03-30 Thread Christian Hilberg
Hi Milan, On Wed 30 March 2011 Milan Crha wrote: On Wed, 2011-03-23 at 19:04 +0100, Christian Hilberg wrote: Of course, this is going to be fun - how to tell which of the possibly multiple EDS-frontends should receive the request? Ideally, the backends should be unaware of EDS-frontends

[Evolution-hackers] Calendar PIM objects with inlined attachments

2011-04-08 Thread Christian Hilberg
Hi everyone. While working on the evolution-kolab plugin, we found that there is no direct support in ECalComponent for attachments inlined into calendar objects. Thus, so far, we can cope with attachments inlined into Kolab calendar objects by hiding them in private ical fields. That way, we

Re: [Evolution-hackers] Calendar PIM objects with inlined attachments

2011-04-08 Thread Christian Hilberg
Hi everyone, thanks for the input so far. On Friday 08 April 2011 David Woodhouse wrote: On Fri, 2011-04-08 at 10:35 +0200, Milan Crha wrote: On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote: We could use Evolution's file-link attachment mechanism by writing into Evos file

Re: [Evolution-hackers] Calendar PIM objects with inlined attachments

2011-04-08 Thread Christian Hilberg
On Friday 08 April 2011 Milan Crha wrote: [...] With respect of fetch on demand, it'll be tricky to achieve, to make this done right on each operation which deals with the calendar component in a certain way (operations like copy, move, send and so on). But there is some API function,

[Evolution-hackers] [evolution-kolab] Vital signs from the project

2011-06-21 Thread Christian Hilberg
Hi everyone. After a prolonged silence and a period of much work, the evolution-kolab team gladly announces what you could call a first release candidate of the Kolab plugin for Evolution (in fact, it is, only it has not officially been tagged as one). Source code, packages, user manual and

[Evolution-hackers] [evolution-kolab] towards Upstream-Integration

2011-07-01 Thread Christian Hilberg
Hi everyone. Since the last announcement of the evolution-kolab team here on the list, our source code (hosted at http://evolution-kolab.sourceforge.net/) has seen some more polishing and now compiles on Debian/Squeeze in addition to Ubuntu/Lucid. We will make available a (source) release

Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration

2011-07-07 Thread Christian Hilberg
Hi, On Thu 07 July 2011, Chenthill wrote: On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote: Since neither my kernel concepts evolution-kolab team mates nor myself have done upstream integration for an Evolution plugin yet, I would like to know how we should best proceed from here

Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration

2011-07-12 Thread Christian Hilberg
Hi everyone, On Thursday 07 July 2011, Matthew Barnes wrote: On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote: The first step could be to create an evolution-kolab git repository at gnome.org, at least this is what came to my mind instantly. In order to get the prerequisites

Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration

2011-07-15 Thread Christian Hilberg
Hi, On Friday, 15 July 2011, Matthew Barnes wrote: Sorry for the delayed response... NP at all, thanks for your input! [...] The process really isn't as formal as the wiki makes it out to be. Because you're an extension module for an application that has already met these requirements,

Re: [Evolution-hackers] Moving EExtension to libedataserver

2011-09-12 Thread Christian Hilberg
Hi all, Am Montag 12 September 2011, um 09:57:26 schrieb Milan Crha: On Fri, 2011-09-09 at 22:18 -0400, Matthew Barnes wrote: I got this working today. Would anyone object if I create the gnome-3-2 branch early next week so I can commit this for 3.3.1 and then rebase my account-mgmt

Re: [Evolution-hackers] Moving EExtension to libedataserver

2011-09-12 Thread Christian Hilberg
Hi there, just one bit of nitpicking: Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: [...] The EExtension framework was introduced in Evolution 2.30 as part of the Shouldn't that read 2.32? At least, the wiki

Re: [Evolution-hackers] Moving EExtension to libedataserver

2011-09-12 Thread Christian Hilberg
Hi again, Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: [...] The API is already fully documented and our wiki has usage instructions for it: http://live.gnome.org/Evolution/Extensions Is the list of EExtensible-tagged classes listed at the end of the wiki

Re: [Evolution-hackers] Moving EExtension to libedataserver

2011-09-12 Thread Christian Hilberg
Hi, I hope I've got the reference right... Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: [...] I'm going to need EExtension for the new D-Bus service I talked about recently [1] anyway, so it makes sense to get this part merged early. Kind regards, Christian

[Evolution-hackers] Evo/E-D-S security (libs) long-term plans

2011-09-12 Thread Christian Hilberg
Hi all. During the initial implementation of the evolution-kolab plugin, we were concerned with using hardware crypto devices (TPM, trusted platform module) as a means to store and retrieve client certificates for securing TLS connections to a Kolab server (by configuring the Kolab server to

Re: [Evolution-hackers] Further thoughts on ESources

2011-09-12 Thread Christian Hilberg
Hi all, Am Donnerstag 25 August 2011, um 18:46:15 schrieb Matthew Barnes: [...] Proposal: I think the key file management needs to be centralized in a new D-Bus service, tentatively called e-source-registry. The ESourceRegistry singleton class in client programs would then be a proxy for

Re: [Evolution-hackers] Evo/E-D-S security (libs) long-term plans

2011-09-13 Thread Christian Hilberg
Hi Milan, Am Dienstag 13 September 2011, um 07:33:31 schrieb Milan Crha: On Mon, 2011-09-12 at 13:16 +0200, Christian Hilberg wrote: We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS. These are protocols handled by Camel and the underlying NSS library. In order

Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin

2011-09-13 Thread Christian Hilberg
schrieb Christian Hilberg: [...] [3] http://mail.gnome.org/archives/evolution-hackers/2011-September/msg00030.html -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed

Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin

2011-09-14 Thread Christian Hilberg
Hi Milan, Am Mittwoch 14 September 2011, um 08:25:20 schrieb Milan Crha: On Tue, 2011-09-13 at 15:56 +0200, Christian Hilberg wrote: * IMAP ACL management. A new tab (or something alike) when right-clicking an IMAP folder in the Evo folder tree to view and edit IMAP access control

Re: [Evolution-hackers] Rethinking account management

2011-09-14 Thread Christian Hilberg
Hi, Am Dienstag 18 Januar 2011, um 20:32:44 schrieb Matthew Barnes: [...] Now I'll let you in on my master plan: Either in the 3.2 or 3.4 time frame, after the branch is merged and has some time to settle in and stabilize, I want to move these configuration dialogs to

Re: [Evolution-hackers] CamelService changes

2011-09-14 Thread Christian Hilberg
Hi there, I know it is muc hlate for input, but anyway, here we go: Am Donnerstag 21 April 2011, um 18:43:27 schrieb Matthew Barnes: To help smooth the way for the account-mgmt I've made a few improvements to the CamelSession and CamelService APIs in 3.1. It's not necessarily the *final*

Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin

2011-09-14 Thread Christian Hilberg
Hi all. Am Dienstag 13 September 2011, um 15:56:00 schrieb Christian Hilberg: The evolution-kolab team is currently planning to port the evolution-kolab plugin to the recent developer version of Evo/E-D-S. I have had a discussion [...] In order to get a clearer picture of the changes in Evo

Re: [Evolution-hackers] [evolution-kolab] On porting and extending the plugin

2011-09-14 Thread Christian Hilberg
Hi all, thanks to Matt, here are another two which I initially missed (since I was much clear that Camel would move to GObject/GError/GIO...): -- Thread:

Re: [Evolution-hackers] A little E-D-S code reorganization

2011-10-05 Thread Christian Hilberg
Hi there, Am Donnerstag 29 September 2011, um 17:35:04 schrieb Matthew Barnes: On Thu, 2011-09-29 at 09:13 +0200, Milan Crha wrote: I think I mentioned it earlier, and maybe this is the right time, what about replacing e- prefix with evolution- prefix for process names? There was a

Re: [Evolution-hackers] Camel Authentication Changes

2011-10-17 Thread Christian Hilberg
Hi Matthew, Am Samstag 15 Oktober 2011, um 17:18:27 schrieb Matthew Barnes: Just a heads up that I've changed Camel's authentication API to factor out the password loop that each and every provider currently replicates for themselves. Turns out they all have the same basic logic flow. [...]

Re: [Evolution-hackers] Camel Authentication Changes

2011-10-17 Thread Christian Hilberg
Hi there, Am Montag 17 Oktober 2011, um 14:51:08 schrieb Matthew Barnes: On Mon, 2011-10-17 at 11:44 +0200, Christian Hilberg wrote: I take it this new password API deals with IMAP|POP|SMTP|... service passwords _only_, i.e. service user authentication? Correct. I don't have a good

Re: [Evolution-hackers] Camel Authentication Changes

2011-10-18 Thread Christian Hilberg
Hi Matthew, Am Montag 17 Oktober 2011, um 23:48:01 schrieb Matthew Barnes: On Mon, 2011-10-17 at 15:21 +0200, Christian Hilberg wrote: Fair enough, thanks for clarifying. If that's the current status, then nothing is lost if we keep the implementation as-is for now and try it again later

[Evolution-hackers] [evolution-kolab] Version 0.30.0 released, moved to gnome.org

2011-11-08 Thread Christian Hilberg
Hi everyone! The evolution-kolab team gladly announces the availability of version 0.30.0 of the evolution-kolab plugin for the Evolution PIM suite. The major improvements over our previous release (Version 0.2.1) include overall speedup fixes to most operations as well as a good number of

Re: [Evolution-hackers] UID in vCard

2011-11-15 Thread Christian Hilberg
Hi everyone, Am Montag 14 November 2011, um 11:22:57 schrieb Milan Crha: On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote: So I suggest to pursue the first approach instead. I think it is possible for the file backend. Is it also possible for other backends? Or are some unable to

Re: [Evolution-hackers] UID in vCard

2011-11-15 Thread Christian Hilberg
Am Dienstag 15 November 2011, um 15:01:54 schrieb Christian Hilberg: Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly: [...] What happens during syncing? Do you resolve the add-add conflict by duplicating the item, merging them or discarding one copy

Re: [Evolution-hackers] Camel no longer depends on libedataserver

2011-11-18 Thread Christian Hilberg
Hi everyone. Am Mittwoch 16 November 2011, um 21:38:59 schrieb Matthew Barnes: On Mon, 2011-11-14 at 23:33 -0500, Matthew Barnes wrote: There is no longer any _technical_ reason why Camel needs to be bundled in the evolution-data-server module. I DO intend to split Camel off at some

Re: [Evolution-hackers] UID in vCard

2011-11-18 Thread Christian Hilberg
Hi Patrick, Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly: Hello! [...] On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote: If a new UID is to be created, it is the responsibility of the Kolab client to assign one. The Kolab server itself is unaware to object

Re: [Evolution-hackers] UID in vCard

2011-11-18 Thread Christian Hilberg
Hi, Am Freitag 18 November 2011, um 16:53:38 schrieb Patrick Ohly: On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote: [...] While the E-D-S client (like Evo) might not be interested whether it is a Kolab backend being used, there is still one thing you may wish to consider here

[Evolution-hackers] [evolution-kolab] new mailing list

2011-12-06 Thread Christian Hilberg
Hi, the evolution-kolab plugin now has a mailing list, please see [1]. Everyone who is interested in following the discussions there is invited to subscribe. I estimate this list to be a low-traffic one, at least for some time. :) I'll post links into the archive of the

Re: [Evolution-hackers] [evolution-kolab] new mailing list

2011-12-07 Thread Christian Hilberg
Hi David, Am Dienstag 06 Dezember 2011, um 22:29:46 schrieb David Woodhouse: On Tue, 2011-12-06 at 17:03 +0100, Christian Hilberg wrote: the evolution-kolab plugin now has a mailing list, please see [1]. Everyone who is interested in following the discussions there is invited to subscribe

[Evolution-hackers] [evolution-kolab] IMAPX code dependency

2012-02-03 Thread Christian Hilberg
Hi everyone. In evolution-kolab [1], we use an IMAPX derivative for accessing the Kolab groupware server via IMAP. Since (a) Camel does not expose IMAPX directly and (b) IMAPX is not yet cleanly subclassable in all aspects and I need to keep a copy of upstream IMAPX in the evolution-kolab

Re: [Evolution-hackers] [evolution-kolab] IMAPX code dependency

2012-02-03 Thread Christian Hilberg
Hi Matt, Am Freitag 03 Februar 2012, um 16:46:50 schrieb Matthew Barnes: On Fri, 2012-02-03 at 15:53 +0100, Christian Hilberg wrote: I need to replicate some code paths of IMAPX (e.g. all paths that lead from the Store to imapx_untagged, so I can extend this one for ANNOTATEMORE and later

Re: [Evolution-hackers] Start your engines for Evolution 3.5.1

2012-03-26 Thread Christian Hilberg
Hi everyone, Am Montag 26 März 2012, um 05:03:14 schrieb Matthew Barnes: You may have noticed Evolution 3.4.0 and co. has been released and I've created 'gnome-3-4' branches for all modules except 'evolution-mapi' and 'evolution-kolab' (but I assume Milan and Christian will take care of those

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-04-03 Thread Christian Hilberg
Hi Matt, thanks a lot for picking up this topic, as it is quite essential for us. Maybe others can join in as well in order to iron out what would be needed here. Am Dienstag 03 April 2012, um 14:14:52 schrieb Matthew Barnes: On Tue, 2012-04-03 at 10:52 +0200, Christian Hilberg wrote: Next

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-04-03 Thread Christian Hilberg
Hi Matt, Am Dienstag 03 April 2012, um 17:11:56 schrieb Matthew Barnes: On Tue, 2012-04-03 at 10:40 -0400, Matthew Barnes wrote: g_network_monitor_can_reach() takes a GSocketConnectable -- which is just an interface that's implemented by several concrete classes like GNetworkAddress (based

Re: [Evolution-hackers] Memory corruption in timezone handling

2012-04-03 Thread Christian Hilberg
Hi, Am Sonntag 01 April 2012, um 11:13:00 schrieb Robie Basak: Hi freeassociation-devel, I think I've tracked down a segfault in evolution to a bug in libical. In icaltimezone.c:icaltimezone_get_builtin_timezone, icalarray_append(builtin_timezones, ...) is called. This can cause

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-04-03 Thread Christian Hilberg
Am Dienstag 03 April 2012, um 18:05:33 schrieb Matthew Barnes: On Tue, 2012-04-03 at 17:29 +0200, Christian Hilberg wrote: Seems to me that opening a connection in order to find out whether I could open a connection is more than evo-kolab would need. Unless the service-available check

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-04-04 Thread Christian Hilberg
2012, um 12:24:58 schrieb Milan Crha: On Tue, 2012-04-03 at 13:33 -0400, Matthew Barnes wrote: On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote: Just rough thinking, nothing elaborate as yet - I'll be meditating this. :) Rough thinking here too. I'll let it simmer

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-04-05 Thread Christian Hilberg
Hi there, Am Mittwoch 04 April 2012, um 19:11:46 schrieb Matthew Barnes: On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote: How about the service-available to be set much like the to-be network-available, through GNetworkMonitor, as an EBackend property, which, when changed, emits

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-04-05 Thread Christian Hilberg
Hi, ...also re-posting here instead of our more private thread, in order to get these things into public, for the record and for discussion: Am Donnerstag 05 April 2012, um 11:09:37 schrieb Milan Crha: Hi, just an out-of-thread idea (initially opened in another discussion): Thinking

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-04-13 Thread Christian Hilberg
Hi, Am Mittwoch 04 April 2012, um 15:09:36 schrieb Milan Crha: On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: [...] As for evolution-kolab, sadly, there is no good way to do a quick check for changes, at least I do not have an idea how one could implement one, since

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-04-13 Thread Christian Hilberg
Hi, Am Freitag 13 April 2012, um 11:54:51 schrieb David Woodhouse: On Tue, 2012-04-10 at 21:51 +0200, Patrick Ohly wrote: On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: Which is the long-term vision for Evolution in this regard? Lack of proper offline support has been my

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-05-08 Thread Christian Hilberg
Hi all, Am Dienstag 08 Mai 2012, um 01:11:50 schrieb Philip Withnall: On Mon, 2012-05-07 at 17:17 +0200, Christian Hilberg wrote: Moreover, there's a GSoC project (see https://live.gnome.org/SummerOfCode2012/Ideas) for a backend cache infrastructure (the Ideas page still outlines

Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

2012-05-08 Thread Christian Hilberg
Hi Matt, Am Montag 07 Mai 2012, um 18:17:05 schrieb Matthew Barnes: On Mon, 2012-05-07 at 17:17 +0200, Christian Hilberg wrote: It has already been agreed upon (see previous posts in this thread) that such a synchronize() function is needed and that it can be triggered from the EClients

Re: [Evolution-hackers] Subclassable and extendable IMAPX

2012-05-23 Thread Christian Hilberg
Hi everyone, had a chat with Chen on IRC today about the topic. Since he had to leave, I'll try to sum up our findings here, for the record and for review, please see the inline comments. Am Mittwoch 23 Mai 2012, um 10:00:27 schrieb Christian Hilberg: Am Dienstag 22 Mai 2012, um 16:38:20

Re: [Evolution-hackers] Subclassable and extendable IMAPX

2012-05-23 Thread Christian Hilberg
Hi again, Am Mittwoch 23 Mai 2012, um 18:05:29 schrieb Christian Hilberg: Passing in the user payload data showed to be specifically tricky. As dwmw2 just pointed out on IRC, it really isn't. The data structures which the derivative untagged handlers need to access can/should best be bound

Re: [Evolution-hackers] Subclassable and extendable IMAPX

2012-05-23 Thread Christian Hilberg
And again... Am Mittwoch 23 Mai 2012, um 18:40:34 schrieb Christian Hilberg: Hi again, Am Mittwoch 23 Mai 2012, um 18:05:29 schrieb Christian Hilberg: Passing in the user payload data showed to be specifically tricky. As dwmw2 just pointed out on IRC, it really isn't. The data

[Evolution-hackers] Updating http://projects.gnome.org/evolution/download.shtml

2012-06-11 Thread Christian Hilberg
Hi everyone. Each time we release a new version of Evolution, E-D-S and the plugins, http://projects.gnome.org/evolution/download.shtml requires a manual update. New plugins, like evolution-kolab, are easily missed in the process. As for the 3.5 line of evolution-kolab, Matt had even added an

  1   2   >