This is a heads up that I will be releasing Evolution 3.5.2 and co. this weekend and then merging the account-mgmt branches for E-D-S, Evolution, and Evolution-EWS. Evolution-MAPI will follow sometime after the merge.
The account-mgmt branch is an effort to overhaul how we manage account information. It solves some long-standing problems in the architecture we've been using for the past decade, and hopefully makes accounts more flexible so we can do new and interesting things we couldn't before. I have documented much of the design decisions and progress over the past 18 months in a thread on this mailing list entitled "Rethinking Account Management" [1]. As this branch represents 18 months of largely non-peer-reviewed work, I'm sure there's going to be bugs and regressions. Just report them as you find them and I'll try to be responsive. My most immediate concern, however, is that account migration works correctly. Bugs can always be fixed, but the migration code typically runs only once. And if I botch that we'll have a royal mess on our hands come Fall. Here's a quick recap of the major changes: * Account data will be removed from GConf and converted to plain text files which live in $HOME/.config/evolution/sources. The file format will be an .ini-like syntax understood by GKeyFile, rather than XML. I have documented the new file format here: https://live.gnome.org/Evolution/ESourceFileFormat * Clients will not access these files directly. Instead, a new D-Bus service named "evolution-source-registry" is introduced to serve these files to clients. Clients will access ESources via a new client-side class named ESourceRegistry. ESourceRegistry is intended to be a singleton instance used by all E-D-S clients as well as our own ECal/EBook factory services. The "evolution-source-registry" service (or just "registry" service) has a few other responsibilities, detailed below. * Authentication attempts are now coordinated between backends and the "registry" service. The service queues all backend requests, handles keyring lookups and password prompting, and securely feeds passwords to backends to test. This takes client applications completely out of the authentication loop. EClient no longer has an "authenticate" signal. This means "headless" E-D-S clients with no main window of their own like evolution-alarm-notify and gnome-shell-calendar-server, as well as E-D-S clients which don't even link to GTK+, can access calendars and address books as easily as applications like Evolution and GNOME Contacts which have historically handled authentication themselves. The "registry" service uses GcrSystemPrompt [2] to display a system modal password prompt. If running a GNOME Shell session, GNOME Shell takes over and displays the prompt as a fancy Javascript-style dialog. This is the same mechanism the gnome-keyring-daemon now uses to prompt users for keyring passwords. ECredentials and e-passwords.c are now deprecated. * The "registry" service is extensible through EExtension the same way Evolution is. I've already written a few extension modules for the service: online-accounts Integrates with GNOME Online Accounts. Basically takes over for Evolution in synchronizing E-D-S sources with GOA accounts. You no longer have to start Evolution for GOA accounts to be noticed. cache-reaper Deletes abandoned cache directories. The reaper scans directories shortly after the service starts up and then once every 24 hours. It lets newly-orphaned directories age a few days before reaping them, in case the account deletion was accidental or cached data needs to be salvaged. It does not touch data directories. google-backend / yahoo-backend These are "collection" backends (described below) for Google and Yahoo! accounts. These are functional but not yet complete. * The "registry" service, through its extension framework, hosts a new kind of backend called a "collection" backend. The term "collection" is borrowed from WebDAV nomenclature. A collection backend's job is to manage a collection of ESources as a single account. Usually this involves querying a remote server for private and shared data sources, setting up equivalent ESource instances to serve as proxies, and then keeping the collection synchronized with the remote server. The idea is if you create, say, a new calendar on a groupware server, the collection backend for that server is supposed to notice the new calendar and assemble an equivalent ESource for it, which is then exported over D-Bus and all active E-D-S clients see it immediately. I've really only just begun to implement collection backends. There's a lot more work to be done here to fully realize what I have in mind. * There will be API breakage at all levels of Evolution-Data-Server, but most severely in libedataserver. ESourceList, ESourceGroup, EAccount, and EAccountList are all gone, replaced by ESourceRegistry. ESource still exists and is conceptually the same as before, but its API is completely different now. It's basically a glorified key file interface with a few asynchronous D-Bus methods. ESource also now handles mail accounts, unifying at last all account management under one API. The new libedataserver and libebackend APIs are documented here: http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ http://mbarnes.fedorapeople.org/account-mgmt/docs/libebackend/ * The account editor and the calendar and address book configuration dialogs have been rewritten from scratch. They no longer use EConfig, nor even EPlugin at all. They are now extended through EExtensions. Now that the config editors are liberated from EPlugin, I'd like to take a serious look at moving them to Evolution-Data-Server. I still need to figure out the details there. * Lastly, the test suite in Evolution-Data-Server is pretty borked at the moment. I hope to get the test suite operational again by 3.6. Now that account information is stored in XDG-compliant directories, we should be able to create a much nicer and fully automated test harness that doesn't risk interfering with your own accounts. I have several patches prepared already for other projects to help them quickly adapt to the API breaks. I'll also be blogging about this today or tomorrow. Matthew Barnes [1] Thread starts here: https://mail.gnome.org/archives/evolution-hackers/2010-November/msg00013.html [2] http://developer.gnome.org/gcr/unstable/GcrSystemPrompt.html _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
