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

List:       kopete-devel
Subject:    [Kopete-devel] more design discussions (an also,KMMF bugs)
From:       Andres Krapf <dae () chez ! com>
Date:       2002-05-08 13:37:39
[Download RAW message or body]

about the KMM and KMM factory:

i think we need the concept of a chat session. a chat session would be 
comprised of:
 - an identity (or, for now, a protocol)
 - a list of users.
 - an equality operator.

right now, we use a KopeteContact* user, and a KopeteContactList others.

 * first on, the bad thing about the way we use KopeteContacts (aka comparing 
pointers) is that nowhere is there a guarantee that the plugins won't create 
more than one per contact. so we either have to
    1/ enforce the KopeteContacts uniqueness, somehow.
or 2/ not rely on pointer comparisons, and overload ==. <- this might lead us 
to bad design with dynamic_casts (or qcasts), but i'm not completely sure.

 * next, for protocols supporting multi user chat, when a protocol needs to 
send a message with a KopeteContactList toKC, the plugin needs to map this 
KopeteContactList with whatever resource it holds that represents the chat 
session. this defeats the purpose of the KMM somehow. (i hope i'm clear 
enough here). here's where a chat session concept would be nice (as opposed 
to a mere list of pointers). the plugins would then just need to map the chat 
session to the underlying resource.

 * in order to allow protocol personalisation of the chatwindow, having an 
optionsWidget() is no good. first because it's not extensible enough (not 
enough control is given to the plugin). next, because the framework will not 
be able to check those values, so the protocol class will have to interact 
with the chatwindow directly (as opposed as going through the KMM and 
KopeteMessages). the sendThroughServer status, for example, could be nicely 
encapsulated inside the ICQMessage subclass for icq.

the best way i see to keep using the nice KMM functionality while allowing 
full customisation is either to allow subclassing of KMMs (which i think is a 
good thing).

if we go that way, there's the probem of the factory. we could use a factory 
method provided by the plugin, but then we'd have to dynamic cast like here:

(inside, say, AIMProtocol class)
/* this calls the KMMF::create which in turns calls some method provided by 
the plugin which creates a AIM specific AIMProtocol*)
*/
KMM* kmm = sessionFactory()->create(blah);

/* we have to dynamic cast */
AIMProtocol* aimkmm = dynamic_cast<AIMProtocol*> kmm;

a better solution might be to use a factory template. like this:

template <class KMMT> class KMMFactory {
	KMMT create (blah) {
		if exists blah inside KMM list
			return KMM list item;
		else
			return new KMMT(blah);
	}
}

so that we reuse the code, but each protocol gets its own factory returning 
its own KMM (AIMKMM, ICQKMM .....) and we don't have to dynamic_cast.

we could still provide the generic KMM for plugins which don't require any 
customization (or aren't there yet).

comments ?

btw, i've found 2 bugs in the current KMMF. can't commit fixes since my local 
factory is different from the cvs one (has the protocol argument, as 
discussed previously on the list). i'll commit those as soon as the protocol 
writers understand what will happen to their plugins once these changes take 
effect, and tell me they're ok with it :-)

i'd like to hear from the people involved in jabber (Daniel ?), msn (i believe 
this is Martijn ? from whom i already had extensive response :-) and possibly 
icq also. i've taken care of keeping my aim in sync with my KMM changes.

if you want a summary of what you will need to change, reread one of my older 
posts in which they are described. it's not very hard.

cheers (and sorry for the length),

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