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* APIs that will wind up in 3.2, but more like the first round > of changes leading up to 3.2. > [...] > * The file storage location for CamelServices (really only CamelStores) > has changed. It is now simply: > > $(XDG_DATA_HOME)/evolution/mail/$(UID) > > rather than: > > $(XDG_DATA_HOME)/evolution/mail/$(PROVIDER_NAME)/$(URL) > > That means each CamelService has a permanent location for files that > doesn't change if the user tweaks server settings or even changes the > provider. > [...] I recall that when I tried to find my way into Camel when using it from within the backend processes for evolution-kolab, I screwed up my provider directory (named 'kolab2' in 2.30) now and then because of wrong Camel use. It was then very easy to recover from the error by just killing my own provider's subdirectory, which was easy to identify (let alone all of the downsides the historic approach may have). Please forgive me for not reading the Camel code here - can one guess from the UID to which account it may belong? What's more, in the current evolution-kolab design for 2.30, we have $(XDG_DATA_HOME)/evolution/mail/$(PROVIDER_NAME)/$(URL) $(XDG_DATA_HOME)/evolution/calendar/$(PROVIDER_NAME)/$(URL) $(XDG_DATA_HOME)/evolution/addressbook/$(PROVIDER_NAME)/$(URL) since we're using CamelStore also in the backends. Hope this will not prove a broken design with the new situation for Camel. Moreover, our pimped IMAPX derivative uses further SQLite databases in addition to the folders.db Camel creates. These are for Kolab metadata and for an offline write cache for Kolab PIM data. The PIM data cache is used in backend context only, while the Kolab folder metadata DB is used by the kolab2 provider run in Evo as well. I hope that changing forth and back the providers for an account will not mess with that. (The Kolab metadata DB is re-created and re-populated in case it is missing, so it should not be problematic during migration.) Kind regards, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.