[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] Address book integration
From:       Martijn Klingens <klingens () kde ! org>
Date:       2003-07-10 10:42:03
[Download RAW message or body]

On Thursday 10 July 2003 11:14, Will Stephenson wrote:
> - mandatory or optional participation in both the Kopete contactlist file
>   and kabc.  The last time kabc integration was discussed this was the
>   issue that divided Kopete developers as I'm sure you'll remember.

Given that Duncan himself most ferociously objected to putting all meta 
contacts in the address book like I wanted I am quite sure the solution will 
incorporate partial storage in kabc and please everyone :)

> - relationship between Kopete structures and kabc.  I'm guessing
>   metacontacts in Kopete <-> kabc entries?

That's what I geared the KMC API towards so I hope that's true :)

> - 2 way integration, for linked records, will we both update kabc as 
>   metacontact contents change and react if kabc's IM address entries are
>   changed outside of Kopete?

We have to, but that is a PITA to get right. Personally I'd rather wait with 
the more intrusive changes until 0.7 is out of the door before Nove Hrady and 
work on the kabc integration from there onwards. 0.7 already has the 
KopeteAccount and much improved stability as selling points, as well as a 
Yahoo plugin and IRC on steroids compared to 0.6. We can use the KABC as 
feature for the next release ;)

> - contact metadata - we were talking last night about how to store buddy
>   icons in kabc,

I understood from Zack that s/th along those lines is already there. Don't 
know what exactly though.

> and we should also have a policy for relating IM obtained contact data to
> that in kabc.  We could limit it to using IM userinfo to populate a 
> new kabc entry generated from a metacontact, but since different protocols 
> support different sets of user info the mapping could be tricky.  I'm 
> interested in this myself as I was augmenting the ICQ userinfo support 
> recently.

Consensus on the various mailing lists was that
- KABC is a generic platform, so Kopete-specific stuff doesn't belong there.
  In particular that means that the storage formats for UIDs should be
  generic so it can be shared with clients like Kit and Licq.
  Hence the 'messaging/foo' format in the KMC API.

- KABC is not a database to dump everything in. Stuff that doesn't reasonably
  belong in a vcard doesn't belong in KABC either. While I would personally
  much prefer a single storage vault I can agree with the reasoning if only
  because vcard is a slow format for large amounts of data and because vcards
  are also stored on memory-bound devices like mobile phones and PDAs.
  For us that means that we will always need contactlist.xml to store
  additional data and use KABC only for the actual linking and the truly
  shared storage.

- Storage _into_ KABC can be done by Kopete directly, though on the longer
  run another API is needed that is partly in kdelibs. The reason is that
  we need generic messaging interfaces that can be shared with other clients.
  Kopete is not a monopoly, the user should be able to replace it with another
  while still retaining the KDE address book functionality.
  As such, selecting a user in a kabc dialog should go through an intermediate
  interface that could use any protocol.

My own planning was to first get the Kopete->KABC side working, then moving 
most of that into a shared interface to be used too by e.g. Kit. Lastly the 
integration from within kaddressbook itself needs to be done, again by using 
shared interfaces.

-- 
Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]