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

List:       kopete-devel
Subject:    Re: [Kopete-devel] Address book integration
From:       Zack Rusin <zack () kde ! org>
Date:       2003-07-10 20:39:26
[Download RAW message or body]

Ave,

I have a moment so lets try this:

On Thursday 10 July 2003 06:42, Martijn Klingens wrote:
> 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
> :)

This seems very familiar, didn't we have this discussion before? :)

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

ACK.


> > - 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 ;)

It's not hard, just a little tricky. You get a method of storage from 
kabc and monitor it with kdirwatcher as soon as something changes you 
switch metacontacts. I might consider adding a dcop call to kabc 
notifying on changes.

> > - 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.

In here you want to use either setPhoto or the setLogo addressee 
methods. I'd think that setLogo is a lot better idea for buddy icons.

> > 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.

I was wondering, what were the examples of some of the Kopete-specific 
fields?

> - 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.

ACK, but I'm still wondering what large amount of data needs Kopete to 
store in the userlist.

> - 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.

You mean as in  adding "pim/messaging" service and then having a dcop 
client that implements it and apps wanting to use that interface simply 
loading it in a similar fashion to what Kontact does?


> 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.

This is mostly beyond the scope of Kopete. KAddressbook itself ignores 
external changes to KABC while it's running. Try starting KMail and 
KAddressbook, now in KMail click on the 'From' header in one of the 
emails and select "Add to Address Book" option. The contact will be 
added but the KAddressbook will only notice the changes after its 
restart.
In general I told Martijn that I'll be working on it sometime soon and 
during n7y hopefully me and him are going to wrap it up. We'll see how 
it goes... :)

Zack

-- 
Failure is not an option. (It comes bundled with Windows.)
_______________________________________________
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]