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

List:       kopete-devel
Subject:    Re: [Kopete-devel] [Long] next release
From:       Andres Krapf <dae () chez ! com>
Date:       2002-04-29 14:18:23
[Download RAW message or body]

> Then you can better add a virtual isSame( const KopeteContact * ) const =
> 0; to KopeteContact. But why not just comparing the pointers? There are
> never more than one instance of the same KopeteContact anyway, or the code
> is broken somewhere.

yes, but suppose i'm a plugin writer and a message comes in. the underlying 
protocol gives me a unique ID that is protocol specific. now i need to create 
a KopeteMessage, which needs (or will need) a KopeteContact "from". how will 
i map the protocol ID to the KopeteContact ?

one solution was proposed by Duncan -> each protocol keeps a QMap for it's own 
specific contacts. this gives more work to plugin developers, and creates a 
need to keep ContactList and each plugin list in sync.

another solution is to use the UniqueId classes i proposed:
 - plugin receives message with protocol specific ID
 - plugin creates a temporary UniqueId (say an AIMUniqueId) for it
 - plugin asks the contact list to return the KopeteContact corresponding to 
the UniqueId
 - contact list iterates through list and compares to each contact's UniqueId 
(or, if you prefer for efficiency reasons, keeps a QMap of those... but 
efficiency is really not an issue here)

the isSame() added to a KopeteContact is not good enough because the plugin 
doesn't have the KopeteContact yet...

advantages are:
 - a centralized place for contacts, no need to sync
 - no duplication of code (or else each plugin will reimplement the QMap 
scheme)
 - probably (not sure though) more generic contact management code

cheers,

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