Re: [Evolution-hackers] Splitting out the address book from evolution?

[Ettore Perazzoli <ettore ximian com>]

Hi,

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 now 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
        addressbook/backend).

      * 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. 
        :-)

-- Ettore