MSNp14 status?

[Ethan Blanton]

Felipe Contreras spake unto us the following wisdom:
> 2008/1/31 Ethan Blanton <elb at pidgin.im>:
> > Felipe Contreras spake unto us the following wisdom:
> > > I think I didn't explain correctly my suggestion:
> > > Whatever the MSN prpl receives from the blist.xml, just drop it.
> >
> > I'm trying to decide if that's a serious suggestion, or not.  Do you
> > mean that MSN buddies should not be able to be placed in contacts,
> > have custom buddy icons associated with them, local aliases, etc.?  Or
> > are you being facetious?  Or is there a third option I do not
> > comprehend?
> 
> First, I already explained what I meant by "drop the blist.xml
> support", I meant drop that from the prpl. The prpl has absolutely no
> knowledge about the custom buddy icons, local aliases. or contact
> stuff, so it can't possibly disable that functionality from libpurple.

Ahh -- so we were on the same page *before* your correction (that is
what I understood that you were saying), and I was confused by your
correction.  I completely agree with you.

> I didn't suggest to disable that functionality, or at least I didn't mean to.
> 
> Currently the MSN prpl "uses" the blist.xml only for synchronization
> of buddies and buddies' groups. I suggested to get rid of that usage.

Amen.

> Now, the situation is confusing with the "local alias". As I already
> explained over and over again, the "local alias" should be renamed to
> "display name"; it doesn't matter the location, that's what you want
> to see instead of his nickname.

Well, this is a protocol-specific argument; MSN users like "display
name".  Other users like different terms.  Pretty much nobody likes
"local alias", but it's reviled equally enough that it hasn't been
changed.  ;-)  I don't like "display name", myself, but I won't claim
it's any worse than "local alias".  I'm staying out of this argument.
;-)

> If you guys decide that the "local alias" stays, along with the
> "remove alias" (remotely stored "display name") and the nickname,
> that's your business. If the display name can be stored on the server,
> I see no reason for the "local alias", the same way a local buddy
> doesn't make sense if there's a remote buddy.

Sure; protocols which can store this on the server, do so.  OSCAR
does, I know, as does XMPP, I believe.  If MSN doesn't, and the server
supports that field, it should.

One thing to keep in mind here is that we really want to look like an
"official" client.  Just because the remote server will accept
whatever goop we throw against it (OSCAR does this, for example)
doesn't mean we should; if the official client doesn't do it, we
(generally) don't either.

> A similar thing happens with the "custom buddy icons". Those can be
> stored on the server, you can store any kind of "document" AFAIK. So
> the question comes again, if you already have a remote custom buddy
> icon, why do you want to store it locally? Let's not get into caching,
> because that requires proper synchronization with timestamps. Not to
> mention that custom buddy icons are a stupid idea, they only make
> sense when you buddy doesn't have a buddy icon already and I wonder if
> anyone actually uses those.

Ditto for the previous point on officiality.  As to custom buddy icons
... I agree, I don't use them.  I don't know if anyone does.

> And about contact information, well, that doesn't have anything to do
> with what I tried to propose, I answered too quickly.

Sure, and the prpl need not know about it anyway.  We're back on the
same page, again.  I agree with you on all of the important points.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080131/67518545/attachment.sig>