Re: [Evolution-hackers] CamelService changes
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 GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 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] CamelService changes
On Wed, 2011-09-14 at 16:43 +0200, Christian Hilberg wrote: Please forgive me for not reading the Camel code here - can one guess from the UID to which account it may belong? Yes, in fact it's trivial now: CamelService.uid == EAccount.uid 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. We'll be moving to UID-based directory names across the board for 3.4: $(XDG_DATA_HOME)/evolution/mail/$(UID) $(XDG_DATA_HOME)/evolution/calendar/$(UID) $(XDG_DATA_HOME)/evolution/addressbook/$(UID) ___ 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] CamelService changes
On Fri, Apr 22, 2011 at 5:54 PM, Matthew Barnes mbar...@redhat.com wrote: On Fri, 2011-04-22 at 11:02 +0530, Srinivasa Ragavan wrote: Mostly sounds fine to me as a complete picture, but do remember of the email-factory branch that I'm working on to run mail on EDS. I now expose an API (and some custom bits) over dbus that corresponds to camel's session/store/folder. http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-session.xml?h=email-factory http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-store.xml?h=email-factory http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-folder.xml?h=email-factory It'd be great if you can finalize on the API soon, which can help me move things from 2.32 to master. But for now, I'm mainly on the 2.32 branch to get a stable state of the engine. Can you please provide some kind of summary of the design you have, either here on the mailing list or on a wiki page, since as far as I know no one else has a good idea of what you're doing or how it works. I've been trying to get everyone to do this when making large changes, so that no one is working away in secret and suddenly shows up with what they think is a finished product. Oh sure, http://wiki.meego.com/Architecture/planning/evolution-data-server/email-design has some high level design/architecture of the daemon. It also has details on the way MeeGo app uses it and some task list. But The high level design/architecture of the daemon is up there. -Srini. ___ 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] CamelService changes
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. * Every CamelService instance now has a unique ID string. This will now be the primary way of identifying CamelServices, rather than comparing URL strings. * Adding new services to the CamelSession and retrieving services from the CamelSession are now distinct operations, replacing the create on demand approach of the past. camel_session_add_service() is a new method that takes a UID string, a CamelURL, a CamelProviderType and a GError and tries to instantiate a new CamelService instance for the information given. camel_session_get_service() now simply takes a UID string, and is a straight-forward hash table look up. It no longer references the returned CamelService, so you don't need to unreference it. * CamelService now implements the GInitable interface, and can fail on instance creation. This replaces its construct() method. * 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. CamelService will handle the migration itself during instance creation by reconstructing the old directory path, testing for existence, and if found, renaming the directory to the new form. This solves bug #546491 and also means we won't be leaving so much junk behind over time in the user's data directory. It will also make it easier to clean up after ourselves when accounts are deleted. * The UIDs given to CamelServices are taken from EAccounts. But because an EAccount describes both a store and transport but has only one UID string, the CamelStore for the EAccount gets the UID string verbatim and the CamelTransport for the EAccount gets the UID + -transport. It's a bit of a kludge for now, but will be cleaned up when the account-mgmt branch lands. * For built-in CamelStores, the UID for the On This Computer store is local, and the UID for the Search Folders store is vfolder. For now these are just hard-coded names. The changes are behaving well for me so far, but I imagine I probably broke a corner case or two in some provider somewhere. Let me know if you see anything amiss. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
