Re: [Evolution-hackers] Moving EExtension to libedataserver
On Wed, 2011-09-07 at 13:07 -0400, Matthew Barnes wrote: > Once 3.3 development is underway, one thing I'd like to do is promote > the EExtension framework in Evolution to libedataserver as a replacement > for e-data-server-module.c. On second thought, libebackend might be a better place for EExtension than libedataserver. Haven't decided yet, but it'll be one of the two. ___ 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 EExtension to libedataserver
Once 3.3 development is underway, one thing I'd like to do is promote the EExtension framework in Evolution to libedataserver as a replacement for e-data-server-module.c. The EExtension framework was introduced in Evolution 2.30 as part of the "kill-bonobo" effort and has proven itself stable and flexible. The API is already fully documented and our wiki has usage instructions for it: http://live.gnome.org/Evolution/Extensions I'm going to need EExtension for the new D-Bus service I talked about recently [1] anyway, so it makes sense to get this part merged early. EBookBackend and ECalBackend will then be derived from EExtension instead of GObject, to be further subclassed by the address book and calendar backend modules. Same pattern as EShellBackend in Evolution. An interesting side-effect is that it will now be possible to write extension modules for e-addressbook-factory and e-calendar-factory which can do things other than just add new backend types. This could prove useful for integration with other desktop services, although I'm at a loss for compelling examples off the top of my head. Possibly the Tracker folks might be interested, or perhaps the D-Bus services should start listening to NetworkManager themselves... just to throw out a couple half-baked ideas. These changes will require a soname bump to the E-D-S backend libraries, but the impact should stay "in the family", so to speak. ___ 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] Rethinking account management
I just pushed a new snapshot of my "account-mgmt" branch for Evolution and Evolution-Data-Server. http://git.gnome.org/browse/evolution/log/?h=account-mgmt http://git.gnome.org/browse/evolution-data-server/log/?h=account-mgmt This is mostly for backup -- I haven't yet reached any particularly significant milestone, and the mailer is currently broken. But it's been a long time since my last public snapshot and I'm about to start messing around with the new D-Bus service I talked about in [1], which will require rewriting some of my own rewrites. I need a fresh backup in case things go pear-shaped. Up-to-date documentation for the new ESource API can still be found at: http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ [1] http://mail.gnome.org/archives/evolution-hackers/2011-August/msg00025.html ___ 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] Fwd: [RFC] Metadata access and storage
What if the interface was 1) independent of Tracker, i.e. any application would be able to use it to access E-D-S, and 2) a desktop standard for accessing application data stores, implemented by many client applications? Would you then still be opposed to it? Anders Feder Den 07-09-2011 03:52, Matthew Barnes skrev: On Tue, 2011-09-06 at 13:47 +0200, Anders Feder wrote: Can you imagine yourselves (the Evolution team) maintaining a component implementing such an interface in Evolution? In a word, no. Tracker already has an Evolution plugin [1] and I would prefer it remain in Tracker where it can be actively maintained by Tracker developers. [1] http://git.gnome.org/browse/tracker/tree/src/plugins/evolution ___ 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
