Alternative MSN prpl

[Felipe Contreras]

On Nov 30, 2007 4:07 AM, Ka-Hing Cheung <khc at hxbc.us> wrote:
> On Fri, 2007-11-30 at 03:46 +0200, Felipe Contreras wrote:
> > 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.
>
> I looked at 5fe788856f6702d18b343443f7f6cb52f1888ab7 in your git repo. I
> see that two functions have been added to fix-purple.h, is that what you
> are proposing? If so, I don't see anything fundamentally wrong with it,
> and I certainly don't mind merging in that.

Yeah, about 5 years ago my implementation of the aliasing stuff had
something like that but it was replaced for the current one.

Basically I propose serv_got_alias and serv_got_nick, where there
current serv_got_alias would be replaced by serv_got_nick, and
serv_got_alias would be the new function.

> > 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.
>
> Can you elaborate?

The group stuff is one example. There should be support for
non-grouped buddies. Support for somehow state that the same buddy
can't be twice on the same group (is the prpl expected to manually
remove the second instance?).

Also, the creation of a conference UI. So effectively from the point
of view of the MSN prpl conferences are created and people
added/removed at any time. That would simplify the MSN prpl code
enormously (which usually means less bugs ;). That was on the to-do
list years ago, and there's nothing yet.

Also I remember disliking the Person/Buddy stuff. If there was some
object that prpls could relate and forget about the multiple instances
of Buddies that would make things easier. A Dude is added/removed,
could be in groups or not, has _one_ display picture, _one_ alias,
_one_ nick. The prpls could deal with this Dude entity directly and
forget all the implementation details (Buddy). I guess passing the
account/screen_name around would also work, but that means each time
there's an operation the prpl has to search for it's "dude list", it
would be much easier to just check the proto_data on the Dude entity.

The dude stuff would also allow not only alias/nick updates, but
virtually any information. And with newer MSN protocols more
information can be stored on the server. Notes, tags, whatever.

I haven't worked on this for a while, so I'm possibly missing some
things. But I think for this brief list you can see why my hopes are
not too high.

-- 
Felipe Contreras