Re: [Evolution-hackers] Rethinking account management

[Matthew Barnes <mbarnes redhat com>]

Let's talk D-Bus.

I've started integrating the redesigned, key-file based ESource APIs in
a branch of Evolution-Data-Server and so far it's actually simplifying
the affected code.  I'm leaving mail aside for now and just focusing on
calendars and address books.

I'm gonna have to remove some functions from libebook and libecal which
don't make sense anymore.  More about those later.  But I also realized
I'm gonna have to change the getCal() and getBook() D-Bus methods.

I was a bit horrified to realize over the weekend the way we select a
backend from the factory processes when requesting a new EBook or ECal.
We convert an ESource object to XML and transmit the -entire- XML string
over D-Bus, only to have the factory process reconstruct the ESource
object from the XML string, extract the URI string from the ESource
object, and extract the scheme from the URI.  The scheme is used as a
hash table key for registered backends.

Holy convoluted design, Bat Man!

With the new APIs, apart from GConf migration we won't be constructing
ESources from XML anymore.  So here's how it's gonna work: getCal() and
getBook() will just take the ESource's UID string, the factory process
will look up the corresponding ESource object from its own registry and
call e_source_get_backend() to get the hash table key.  Done.

That part's easy.  What I'm concerned about is avoiding a repeat of the
issues we encountered last cycle when we changed the local backend name
from "file" to "local".  In particular, we need to make sure the client
and servers are using the same D-Bus API at run time.  This is proving
to be a real problem as users upgrade from Evolution 2.30 to 2.32 but
leave the factory processes from 2.30 running.

There's some debate about the best way to handle D-Bus API changes, but
after talking to a few colleagues it seems the simplest approach is to
append a digit to the interface name, like we do for shared libraries.

I kinda wanted to tweak the names anyway, so here's my proposal for the
new D-Bus interface names:

  Old: org.gnome.evolution.dataserver.addressbook.BookFactory
       org.gnome.evolution.dataserver.calendar.CalFactory
       org.gnome.evolution.dataserver.addressbook.Book
       org.gnome.evolution.dataserver.calendar.Cal

  New: org.gnome.evolution.dataserver.AddressBookFactory.0
       org.gnome.evolution.dataserver.CalendarFactory.0
       org.gnome.evolution.dataserver.AddressBook.0
       org.gnome.evolution.dataserver.Calendar.0

In the future, if we have to break a D-Bus interface again we'll
increment the digit.  Then if the user upgrades E-D-S to a version that
implements "Calendar.1" but is still running an e-calendar-factory that
implements "Calendar.0", then when Evolution is launched the session bus
will have to relaunch the upgraded e-calendar-factory binary and the old
e-calendar-factory process will lose its well-known D-Bus name (at least
I think that's how it works... in any case, D-Bus knows what to do).

If there's no objections I'd like to get new interface names into 2.91
now so I can increment the interface versions on my account-management
branch and not have to worry about this anymore.