Alternative MSN prpl
felipe.contreras at gmail.com
Fri Nov 30 06:52:15 EST 2007
On Nov 30, 2007 5:31 AM, Richard Laager <rlaager at wiktel.com> 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.
> >  https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1230017&group_id=235
> The whole MSNP1 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.
I don't know about post MSNP11 stuff. But I remember the problem with
MSNP10/11 was the difference in opinion on how that thing should work.
I stayed all the way waiting for some feedback, but nothing happened.
Until the MSNP14 SoC project came, at which point it was obvious that
the effort we where doing was going directly to the trash bin.
There where also problems with communication and shared development, I
think if we would have used some form of distributed scm things would
have been much easier, but still that wouldn't have changed the fact
that I didn't agree with nosnilmot
I don't remember clearly, but from what I can read on the bug report
the main issue is that Pidgin doesn't have the concept of un-grouped
buddies. So what nosnilmot was suggesting was to emulate the current
behavior, so when we have a buddy on "Friends" and "Ungrouped" then a
new "Ungrouped" group is created on the server and the buddy added
there. It all sounds very good until you log in into an official
client and you see all the mess that Pidgin did.
I expressed my concern and I never heard anything back.
I don't think the code was unmergable, and I think it would have been
a good step towards MSNP14/15, because essentially the main change for
MSNP10 is the way groups work, if somehow those could be fixed and
merged in the current code, it would be easier to track the bugs and
fix them without having to deal with all the other crap needed for
newer protocol versions.
But I guess the developers at that time knew better.
More information about the Devel