From kopete-devel Wed May 08 13:37:39 2002 From: Andres Krapf Date: Wed, 08 May 2002 13:37:39 +0000 To: kopete-devel Subject: [Kopete-devel] more design discussions (an also,KMMF bugs) X-MARC-Message: https://marc.info/?l=kopete-devel&m=102086514627962 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 kmm; a better solution might be to use a factory template. like this: template 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