Re: [Evolution-hackers] CamelService changes

Hey Matt,

On Thu, Apr 21, 2011 at 10:13 PM, Matthew Barnes <mbarnes redhat com> 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.

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.


> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]