[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 21:14:17
[Download RAW message or body]

On Thursday 10 July 2003 22:39, Zack Rusin wrote:
> 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.

A DCOP signal would be welcome here indeed. As you pointed out even 
KAddresbook doesn't pick up changes as of now, which I personally consider a 
serious deficiency.

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

Could be anything, really.

Off the top of my head, everything but the UID, some might be candidates for 
storage in KABC, but for none this is sure:

- The local nickname (not the display name of the entire meta contact) for
  each protocol.
- AOL buddy icons (or MSN 6 when we support it), esp. when different or
  incompatible with KABC's images
- Custom away statuses
- Extra fields that MSN allows for a contact like phone numbers
- GPG keys (though these REALLY belong in kabc and should be shared between
  Kopete and KMail).
- Groups a user is in (personally I'd prefer using the KABC groups, but I am
  not 100% everyone wants that and even less sure KABC supports all
  requirements that we have (like, in MSN a user can be in multiple groups
  at the same time, and while I detest the feature we have to support contact
  lists that have this).
- Whether or not to have feature X enabled for user Y (currently not supported
  but I would like to see that some day in the future for stuff like GPG so
  it's a toggle that can be per-user or per-group overridden).
- The account preference order for contacting a user

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

The above, and in the future it might become more if there's more support for 
per-contact and per-group overrides of global settings.

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

Yup. Though I was thinking more along the lines of starting an external app 
with arguments and not using a plugin system to keep the amount of changes to 
Kit, Kopete, etc. minimal, but yes.

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

Sure. But if you want to invite a user for remote desktop sharing or a 
multiplayer game libkabc or a new libmessaging should display a dialog with 
ALL contacts registered through KABC with messaging enabled, regardless of 
the backend client (Kit, Licq, ...). This libmessaging the uses generic 
interfaces to query the backend apps and do what it needs to do. I don't want 
to see Kopete being hardwired for functionality like this.

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

Indeed. Looking forward to it :)

Wasn't Will coming too?

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