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

List:       kopete-devel
Subject:    Re: [Kopete-devel] [Long] next release
From:       Martijn Klingens <mklingens () ism ! nl>
Date:       2002-04-29 14:36:06
[Download RAW message or body]

On Monday 29 April 2002 16:18, Andres Krapf wrote:
> 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 ?

Like in MSN: QMap<QString ID, MSNContact *contact> m_contacts;

it's a private data member.

> one solution was proposed by Duncan -> each protocol keeps a QMap for it's
> own specific contacts.

I proposed this to him, because a single QMap is so riduculously easy (and 
most protocols need it anyway) that there is no reason not to. The contact is 
the central data entity and hence should be used as soon as possibly. On 
incoming data the plugin should just map the userid to the contact and use 
that everywhere. No stupid plain string passing around everywhere.

> this gives more work to plugin developers, and

See above: hardly.

> creates a need to keep ContactList and each plugin list in sync.

Hmm? What do you mean by this?

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

Well, the code to iterate through a list is MUCH more difficult to write or 
read. Really, the QMap is by far the fastest approach code-wise. 
Performance-wise I don't know. As you said, it's not that much of an issue...

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

Huh? How can't it have it yet? The contact is created and added to the list 
waaaay before KMM even comes into play. Or am I missing a point here?

> advantages are:
>  - a centralized place for contacts, no need to sync

Again, please explain this item.

>  - no duplication of code (or else each plugin will reimplement the QMap
> scheme)

Yes, and the QMap code is so simple that I think that's not an issue. Code 
duplication for one-liners (literally!) ? ;-)

There is only a single method regarding the map that is not a one-liner, which 
is the reverse mapping. and that is exactly the one that would have to be 
created for each plugin anyway if you use UniqueId instead.

>  - probably (not sure though) more generic contact management code

Maybe, but I fail to see that then ;-)

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]