Re: [Evolution-hackers] New 'eclient' branch in eds
On Thu, 2011-04-21 at 08:41 +0200, Milan Crha wrote: > void e_client_open_new (ESource *source, gboolean (* auth_cb) (EClient > *client, ECredentials *credentials, gpointer user_data), gpointer > user_data); > > gboolean e_client_open_new_finish (GAsyncResult *result, EClient > **client, GError **error); I'd would rather ECredentials be an object that gets passed to the "new" function. ___ 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] Moving Evolution-EWS to GNOME infrastructure.
We should move EWS developnent to GNOME infrastructure. I'll work out how to import the GIT repository and add a bugzilla component for evolution-ews. Pavel, Or and Mandy you will need to apply for a GNOME git account, following the procedure at http://live.gnome.org/NewAccounts -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ 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] New 'eclient' branch in eds
On Thu, 2011-04-21 at 08:34 -0400, Matthew Barnes wrote: > On Thu, 2011-04-21 at 08:41 +0200, Milan Crha wrote: > > void e_client_open_new (ESource *source, gboolean (* auth_cb) (EClient > > *client, ECredentials *credentials, gpointer user_data), gpointer > > user_data); > > > > gboolean e_client_open_new_finish (GAsyncResult *result, EClient > > **client, GError **error); > > I'd would rather ECredentials be an object that gets passed to the "new" > function. It's technically not passed in this function, it's a callback signature. :) It would be used as a signal handler for "auth-required" signal in the function, as I think of it right now. Milan ___ 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] Moving Evolution-EWS to GNOME infrastructure.
On Thu, 2011-04-21 at 14:49 +0100, David Woodhouse wrote: > We should move EWS developnent to GNOME infrastructure. > > I'll work out how to import the GIT repository and add a bugzilla > component for evolution-ews. Hi, I understood that Chen wants this as a part of evolution-collab, where, as I understood it, will be added also evolution-exchange, evolution-mapi, groupwise bits, and one day, maybe also evolution-kolab. It may save you from bugzilla and new module procedure work, as Chen will do this all for you for free. Bye, Milan ___ 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] Moving Evolution-EWS to GNOME infrastructure.
On Thu, 2011-04-21 at 17:36 +0200, Milan Crha wrote: > I understood that Chen wants this as a part of evolution-collab, where, > as I understood it, will be added also evolution-exchange, > evolution-mapi, groupwise bits, and one day, maybe also evolution-kolab. > It may save you from bugzilla and new module procedure work, as Chen > will do this all for you for free. Ah, are we still actually going ahead with that plan? I know it's been discussed for some time... -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ 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] New 'eclient' branch in eds
On Thu, 2011-04-21 at 17:11 +0200, Milan Crha wrote: > It's technically not passed in this function, it's a callback > signature. :) It would be used as a signal handler for "auth-required" > signal in the function, as I think of it right now. Yeah I'd like to kill the "auth-required" signal too as I've explained already. ___ 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
Re: [Evolution-hackers] CamelService changes
Hey Matt, On Thu, Apr 21, 2011 at 10:13 PM, Matthew Barnes wrote: > 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. 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. -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 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] Moving Evolution-EWS to GNOME infrastructure.
On Thu, Apr 21, 2011 at 9:24 PM, David Woodhouse wrote: > On Thu, 2011-04-21 at 17:36 +0200, Milan Crha wrote: >> I understood that Chen wants this as a part of evolution-collab, where, >> as I understood it, will be added also evolution-exchange, >> evolution-mapi, groupwise bits, and one day, maybe also evolution-kolab. >> It may save you from bugzilla and new module procedure work, as Chen >> will do this all for you for free. > > Ah, are we still actually going ahead with that plan? I know it's been > discussed for some time... I have the tarballs ready with me. Will get them into git.gnome.org repo. by next week and you can import ews code also by the same time.. Thanks, Chenthill. > > -- > David Woodhouse Open Source Technology Centre > david.woodho...@intel.com Intel Corporation > > ___ > 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 mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
