Re: [Evolution-hackers] Splitting out the address book from evolution?
- From: Andrew Sobala <aes gnome org>
- To: Ettore Perazzoli <ettore ximian com>
- Cc: Evolution Hackers <evolution-hackers lists ximian com>
- Subject: Re: [Evolution-hackers] Splitting out the address book from evolution?
- Date: 21 Jul 2003 23:16:17 +0100
It sounds like a bigger job than I really have time to take on at the
moment, so I'm afraid I don't think it's worth me learning evolution
internals to help you here. (Sorry!)
Still, this sounds absolutely great and I look forward to a grand
unified GNOME addressbook.
Andrew Sobala <aes gnome org>
On Mon, 2003-07-21 at 20:47, Ettore Perazzoli wrote:
> On Mon, 2003-07-21 at 10:47, Andrew Sobala wrote:
> > Something that I think would be really useful for GNOME would be to have
> > a "global" address book that can be used by evolution, gnomemeeting, IM
> > clients, etc.
> > The main requirements would be a) to be able to be accessed from any
> > application, and b) for an application to be able to add a "custom
> > field" for anything that isn't supported already by the address book.
> Yeah, actually this has been the source of some heated internal debates
> lately. I have been discussing this with Chris for a while now, and
> although we don't have a plan that works right now, we are getting
> closer. :-)
> In an ideal world, we want to:
> * Split out Evolution's components (see the UI discussions) so
> that we can get rid of the local folder tree. This way we can
> stick a list of configured addressbooks in GConf, and other apps
> can access it. (We can put the list in GConf right n theow too, but
> it would be awkward since we would have to keep that in sync
> with the actual representation on disk.)
> * Simplify EBook (the API that Evolution uses to access its
> addressbooks) so that it becomes easier to use outside of Evo.
> This implies removing some of the cruft and making a nice,
> synchronous API that doesn't require the caller to go through
> all sorts of pains to use it. Chris posted a prototype of a
> possible new EBook API a while ago and he also has some
> prototype code on CVS (toshok_syncapi_branch in
> * Give CalClient a similar treatment.
> * Make a package out of the new EBook and CalClient libraries plus
> Wombat, and ask for it to be part of the core GNOME platform.
> (Of course some renaming would be in order at that point.)
> The main issue is that the last three points might require a large
> amount of work (porting the addressbook and the calendar to the new API
> could take a while) and we are quite resource-constrained... So maybe
> there are other options:
> * Split out the current version of Wombat/EBook/CalClient without
> refactoring them, and postpone the rearchitecting of the API to
> a later time. Pros: little work, people can have an API pretty
> soon. Cons: current APIs are not that nice.
> * Implement a nicer addressbook/calendar API on top of what we
> have now and make it available, even though Evolution won't be
> using it, at least initially. Pros: we develop nice APIs that
> could be used by other apps. Cons: we'll have to maintain two
> APIs instead of one and since we won't actually be using the
> published APIs they might end up stagnating and getting buggy.
> * Recruit some new Evolution volunteers to do some of the work.
] [Thread Prev