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

[Andrew Sobala <aes gnome org>]

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.

Rock on,

-- 
Andrew Sobala <aes gnome org>


On Mon, 2003-07-21 at 20:47, Ettore Perazzoli wrote:
> 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 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
>         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. 
>         :-)