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

List:       kopete-devel
Subject:    Re: [kopete-devel] Kopete Development Status
From:       Duncan Mac-Vicar <duncan () kde ! org>
Date:       2005-11-16 20:31:07
Message-ID: 200511162131.07647.duncan () kde ! org
[Download RAW message or body]

On Wednesday 16 November 2005 11:21, Olivier Goffart wrote:
> I'd like to know WHO is going to work on kopete and on what branch.
> Personally, i'd like to work on trunk, to refactor libkopete.  But i don't
> want to do it alone.
> It would be nice if poeple could reply this mail to see who will work
> where.

I will work in trunk

Basically with Will we want to come out refactoring the contact list backend.

I dont velieve in rewrites or "this is the perfect design or API", but 
iterative changes. 

What problem are we trying to solve (this was recopilated by Will and 
available on the wiki)

DUPLICATION of grouping of multiple IM addresses into the person using them. 
In libkopete, we have Kopete\:\:MetaContact and its child Kopete::Contacts. 
Then in KABC we mirror this in the KABC\:\:Addressee with a set of custom 
fields. This leads to problems with 
 CONSISTENCY
as Addressees can be deleted while Kopete is not running, it then has to 
update its copy of the grouping. Also IM addresses can be edited in Kontact 
while Kopete is running, and this case is not currently handled. 
COMPLEXITY
 at save time, the current code emits a signal, causing all plugins/protocols 
to write their data into a structure of nested QMaps, then this is written 
out as XML. Code complexity, both as run time (load/save speed) and as a 
barrier to understanding, is high. 
PORTABILITY
 The monolithic contactlist.xml file is hard to sync between different KDE 
installs. 
OPAQUE USE OF KDE ADDRESSBOOK
Currently, users have to optionally select the KABC contact to be able to 
benefit at all from addressbook integration. This should become transparent.

A doable divide an conquer roadmap could be. This basically means:

- ignore metacontacts from contact list when loading
- read the contact ids from the addressbook (custom IM fields)
- protocols still store contact/server cached specific information by their 
own, using a service in libkopete (right now the same contact list)
- visualize the contacts that are in the same addressee toghether in the GUI
- use the kabc groups

- when adding contacts, ask always for a addresse. You can use one in your own 
resource , create a new one, or use a kopete default one.

there are some behaviours that need to be defined. But the complexity of the 
code, and the protocols itself could be hugely minimized by achieving this. 
Also good time to come with tests, and get rid of some mess like Group, the 
addressBookField stuff, the contact list flow itself, etc.

Duncan

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