Alternative MSN prpl

[Felipe Contreras]

On Nov 29, 2007 6:32 PM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> Felipe Contreras wrote:
> <snip>
> > I would like to hear your comments. Best regards.
>
> I have a few comments:
>
> 1.  "Real" server aliases should have been submitted to us as a patch.  We do
> server aliases on other protocols.

Well, you have something that I assume is more official, which is
serv_got_alias, but you don't have serv_got_real_alias, or something.
So the prpls need to call purple_blist_alias_buddy, which is curious,
because you have serv_got_alias for purple_blist_server_alias_buddy,
but nothing for purple_blist_alias_buddy.

I know there's a proper way to do this, but I won't wait for some
consensus among the developers about what is the proper way to set a
real alias. I have stated many times before my opinion that
libpurple's concept of "server alias" is flawed, I just don't care
anymore about proper ways.

> 2.  MSN p2p file transfers should also be submitted to us as a patch.  We would
> certainly be willing to accept a well-written patch to implement said feature.

Of course, just like the series of MSNP10 patches I helped to build up [1].

> 3.  By saying you intend to continue not to follow "any Pidgin best practices",
> does that mean you intend to violate the core/ui split and trample on the work
> that had been going on from the GTK+ 2 rewrite until 2.0.0beta4 was released?
> While third-party plugins can do whatever they want, violating the core/ui split
> would be fundamentally stupid, in my opinion.

I agree it would be fundamentally stupid... if the core's API for
prpls was sane.

I probably can't convince you, but the core's API for MSN is just not
right. So instead of waiting for miracles to happen on the core, I
prefer to write hacky workarounds to make the MSN prpl work as it
should.

> 4.  I personally would have used a monotone branch for this instead of git, but
> that's just me.

Indeed. Certainly not me.

> 5.  We welcome patches too.

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] https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1230017&group_id=235

-- 
Felipe Contreras