Alternative MSN prpl

Felipe Contreras felipe.contreras at
Fri Nov 30 07:58:05 EST 2007

On Nov 30, 2007 6:59 AM, Gary Kramlich <grim at> wrote:
> Hash: SHA1
> Luke Schierer wrote:
> > On Thu, Nov 29, 2007 at 10:02:44PM -0600, Gary Kramlich wrote:
> >> Hash: SHA1
> >>
> >> Richard Laager wrote:
> >>> On Fri, 2007-11-30 at 03:46 +0200, Felipe Contreras wrote:
> >>>> I'm sure you do. But I'm not eager to go into the process of waiting
> >>>> for months for my patches to get some feedback, let alone acceptance.
> >>>>
> >>>> [1]
> >>> The whole MSNP1[1234] upgrade has been problematic because nobody stuck
> >>> with the development effort all the way through. People would show up,
> >>> hack on the code for a bit and then give up in frustration because it
> >>> was so bad. If the code was mergeable, it would've been merged.
> >>>
> >>> Richard
> >> If the code is really this bad, then someone needs to stop adding
> >> features and review it.  And when they're done reviewing it come up with
> >> a decent plan, and make it clean.  And then repeat so that I can stop
> >> hearing about how busted and ugly MSN is, and so that people don't need
> >> to rewrite it out of tree.  If it requires core updates, then let's do
> >> the core updates and force 3.0.0 and get other stuff that's waiting on
> >> 3.0.0.
> >
> > *rant*
> >
> > No one ever wants to do this sort of work in tree.  No one ever wants to
> > do it at all really, *anything* takes precidence over fixing partially
> > written code.
> >
> > */rant*
> >
> > luke
> The big problem I see here is that no one has documented exactly what is
> wrong (read as ugly) about the current code.  Someone please tell me how
> in the hell this is susposed to get fixed if there problem is never
> presented.

I guess It's easy to get lost on the current code, but I would like to
see specific examples of why it's wrong, and perhaps an example of a
better implementation.

There are different layers on the code:
* The login stuff (which uses SOAP)
* The ab stuff (which uses SOAP too, but only on new versions of the protocol)
* The command based stuff (the good old stuff which is plain and simple)
* The MSNP2P (ugly as hell)

SOAP stuff is going to be always ugly unless some SOAP framework is
used and WSDL's.

The MSNP2P stuff is quite complicated and IMHO it works mostly because
I really knew what was happening at the time I did it, and people have
been finding bugs and fixing them. Documenting MSNP2P is a daunting
task and a lot of people have tried and given up. The good thing is
that this is an upper layer, so anyone can just remove the code and
start a new implementation--yeah... right--.

The command based stuff is simple, but in order to use it properly
commands and responses need to be tracked, and one way to do that is
with a bunch of response callbacks, as it is implemented now. That
makes the code a little spaghetti like, but it's not too difficult do
understand what's happening, the only problem is the sequence of
events, that takes time to understand from the code.

There's another much simpler option, which is to implement the
sequence in the code itself, kind of like this:

The code is much simpler, but it will lock waiting for a reply on the
server. So to use it properly in Pidgin a thread would be required for
that, and since last time I checked Pidgin is single threaded, there
are not many options here.

Felipe Contreras

More information about the Devel mailing list