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

List:       kopete-devel
Subject:    Re: [Kopete-devel] MSN Patch
From:       Richard Stellingwerff <mortallic () multiweb ! nl>
Date:       2002-06-22 20:15:06
[Download RAW message or body]

Okay, I spoke with Martijn about this on IRC.

Martijn is currently working on KopeteMetaContact, which will take care of 
sending messages to the protocols. It will also implement queuing, so the 
protocols will not have to worry about that.

To avoid duplicatoin, I will not implement this in MSN. The patch has been 
comitted anyway, since it didn't involve queuing.

-
Richard.


On Saturday 22 June 2002 22:01, Richard Stellingwerff wrote:
> Martijn,
>
> I've got an patch waiting to be commited that I'd like to have reviewed. It
> involves a little internal design change, and it's only half of what really
> needs to be done.
>
> In a nutshell, the patch does these things:
> - It lets MSNProtocol know when a switchboard has closed, so it can be
> removed from the list.
> - Messages sent by users using CCMSN are now displayed.
> - Minor code refreshments ;)
>
> In more detail:
> MSNSwitchBoard will now emit a signal when the socket has closed, with
> itself as parameter. MSNProtocol will catch this signal, and remove the
> switchboard from the list. Now when a new message is sent, a new
> switchboard will be created if none exists. The message is however
> discarded.... But I'll get to that.
>
> CCMSN doesn't send the content-type of a normal message. The MSN Plugin
> used to discard messages, but now I've just asumed that messages with no
> content-type are simply text messages.
> When the X-MMS-IM-Format thing is not specified, it will not try to extract
> the font properties. There's also a little fix in the regexp used to
> extract the font name.
>
> What needs to be done:
> Since creating a switchboard takes a little while, i need to queue the
> message(s) pending. I was thinking of doing this inside the
> MSNSwitchBoardSocket.
>
> However, in order to use a queue, we need to get a new switchboard
> RIGHTAWAY, and not delayed. So I was thinking about creating a new
> MSNSwitchBoard socket inside MSNProtocol::slotStartChatSession(), right
> after sending the request for a switchboard socket (and not when
> confirmed). Then, once we receive the information needed to actually
> connect to the SwitchBoard socket, we call
> MSNSwitchBoardSocket::connectToSwitchBoard().
>
> The advantage of this, is that we can already queue messages before the
> switchboard connection has actually been created. This approach may come
> with some bugs at first, but in the long run, i think it's definately worth
> it. I ofcourse hope to have a bugfree* implementation by the release of
> 0.5.
>
>
> Please tell me your thoughts on this patch, and lemme know if anything
> needs changed. As soon as I can commit this, I'll feel "safe" hacking up
> MSN completely without destroying what I've fixed already. ;)
>
> Do note that this patch is not a horrible one (even though it might sound
> like that now). In fact it works better than 0.4.1 (not that hard to
> archieve, though... :P).
>
> I attached the patch, and uploaded the updated files to
> http://www.linuxfromscratch.org/~remenic/kopete/msn/.
>
>
> Regards,
> Richard.
>
> * there is not really such thing, is there?

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