On Saturday 11 May 2002 01:58, Martijn Klingens wrote:

> plugins though. I think we should aim for this in the longer term and for
> now just _assume_ this is the case, fixing issues where they might arise
> (valgrind, anyone? ;-).

yeah, i'm just pointing out that we are making an assumption.. and a framework 
should not make assumptions like this unless it enforces them. of course for 
now we can just live with it, no pb.

> Well, KMM *is* the chat session... I think the contact list attribute can
> be moved out of the KopeteMessage class once all plugins use KMM. For now
> there might be code using KopeteMessage directly, so this cannot be done
> yet. Maybe in the branch? Not sure.

okay, using the KMM as the chat session is a good solution.

[on plugin personalization]
> I discussed that tuesday night with Nick Betcher and Ian Reinhard Geiser. I
> hope something fruitful will arise from that discussion as I don't have
> time to code my share of the work the upcoming days.

is there a way to be part of those discussions ?

> The protocol should not even know about the chatwindow's existence,
> actually. The chat window is an implementation detail and should not be
> exposed in the design's API. KMM is the only interface to the chat window,
> direct access should be *strictly* forbidden. That's easy enough by moving
> the code out of libkopete into the src/ dir, so it's no longer public
> API...

ideally, the protocol shouldn't know at all about a chatwindow. that's my 
point exactly :-)

now let's take an example, icq's sendthroughserver.
the participating actors are:
 - the chatwindow, or more precisely the STS checkbox
 - the KMM which catches the signal and creates the KM
 - the protocol which sends it

when the protocol is called upon to send the message, it has to know whether 
the user wants to send it through the server or not. this information is held 
by a chatwindow element (the checkbox). and the protocol should not know 
about chatwindows, as we already stated. therefore the KMM has to take care 
of it, and pass on the information to the protocol.

what's the catch ? well, the libkopete generic KMM can't do that, because we 
don't want to put every single option of every protocol in the generic KMM. 
that's not good design (i think you'll agree here).

so how to solve this ? my solution was to allow to subclass KMM, to get 
further functionality.

> Subclassing KopeteMessage?!? Are you kidding? I'm not even happy with
> KopeteMessage inheriting QObject

it doesn't. after our previous discussion, i've backed out my local changes on 
this, and i just call a KMM::messageSuccessfullySent() or something like that 
from the protocol. i wanted to commit those tonight, but may be i'll send 
them to Ian instead.

> Again, KMM should be a single entry point that just encapsulates messaging.
> If there is anything in KMM that could even remotely require
> plugin-specific changes then I think our current design is severely broken.

see my sendthroughserver example above...

> > (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;
>
> ??? Are you casting a KMM to a KopeteProtocol subclass???

sorry, was on crack...
AIMMessageManager* aimkmm = dynamic_cast<AIMMessageManager*> 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);
> > 	}
> > }

> Yes: what the heck do you need this for? It is extremely complex, messy and
> sounds seriously overengineered to me. Is there a *need* for this or are
> you thinking about things like 'well, we _might_ want to do blah in the
> very distant future and then we need this' ?

this is a more elegant solution to the dynamic_cast proposed up there. and 
there is a need for solving the aformentioned problem, if we want kopete 0.4 
to support the same functionality as kopete 0.3 (see icq's 
sendthroughserver's example).

now i'm not saying my solution is the best or even good, it's just a solution. 
may be there is a simpler/better approach, i'd really like to hear it :-)

cheers,

-- 
Andres
_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel