[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 <klingens () kde ! org>
Date:       2002-04-29 13:02:39
[Download RAW message or body]

> I dont like Trillian's approach too much, I prefer server side contacts.
> Trillian approach breaks the rule of plugins.
> Trillian contact list is basically a XML file like
>
> <contact id="lala@lala.org" protocol="msn">Duncan</contact>
>
> In this cae protocol would be ilegal in Kopete, because Kopete is
> now knowing about plugins.

This is not entirely true. Well, in the Trillian approach it is, but we can do 
better than that ;-)

I proposed to you on IRC before two methods to KopeteContact:

virtual QString KopeteContact::serialize() const = 0;

and

virtual void KopeteContact::deSerialize( const QString &data ) = 0;

With those two Kopete can ask the plugin to encode all relevant data in a 
string and decode it again next time, still allowing a centralized contact 
list. Too much code duplication to split contact list handling per plugin if 
you ask me, not to mention it's ugly anyway and would lead to the same 
problem we have currently with all plugins handling chats themselves. 
(Feature X is only in protocol Y, but not in Z.)

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]