[Evolution-hackers] Evolution 2.28.3 - change default mail folder (continued)

2010-08-06 Thread Joop Beekmans
Hi,

I'm trying to move all the local stored (Ubuntu lucid) Evolution mail-
and other relevant data to a Network Storage device, so I can get to my
mail, contacts and calendar from a centralized point in the house.

First I simply tried to softlink the .evolution directory to the new
location (NFS), but Evolution would not start any longer after that. 

Digging a little deeper, I found this message on an Evo mailinglist
describing more or less the same issue:
http://osdir.com/ml/evolution-list/2010-07/msg00337.html

It seems that the proposed solution is what I'm looking for (although
I'm using Evolution version 2.28.3).

Now, it propably is a dumb question, but will this indeed work? And if
so, how exactly do I change the variables mentioned in the message above
to point to my NAS storage device? I'm not much of a Linux expert, so
bring it to me gently... :-) Many thanks in advance.

Joop Beekmans
The Netherlands

___
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 (?)

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 no infrastructure for handling client
  certificates at all [1] and GnuTLS does not seem to handle that by
  itself the way NSS does.
 Hmm, then perhaps CamelHttpStream might be a good stopgap after all.  Be
 aware that I have marked it as deprecated and do still plan to remove it
 after we transition to WebKit, but perhaps by then Dan's TLS work for
 GIO will have landed.

Since we are developing against Evo 2.30, my thoughts are the same. I'll try 
to wrap up CamelHttpStream usage in a way that should make it easy (hopefully) 
to replace CamelHttpStream by some true HTTP lib later on.

Thanks and kind 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 (?)

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 that. Sadly, it won't help us right now, but it is good to 
know that we'll be able to drop CamelHttpStream once this will be working.

 [...] 
 You might be interested in the talk that I gave at GUADEC which
 addresses this and outlines our current effort to make things like
 client certificates and key storage work far simply and reliably across
 GNOME.
 
 http://stef.thewalter.net/2010/07/my-talk-usable-crypto-on-gnome.html

We'll check that out, thanks for the bits! :-)

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


[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 Camel provider instances of 
the same type (i.e. IMAPX)? Note that each provider should cache it's data 
separately.

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