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. _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers