[Adium-devl] MSNP15 in Libpurple

[John Bailey]

Felipe Contreras wrote:
> Indeed, msn-pecan is just about to have basic support for offline
> messages (read only). MSNP15 should have full support.

Our MSNP15 plugin does have full OIM support.  It also supports the "Now
Playing" or "Current Media" information or whatever it's properly called on MSN
(both sending and receiving, I believe) via a status attribute in the same
manner that our XMPP plugin supports this.  Thus, abusing the status message for
the currently playing song is no longer necessary on these protocols.  I believe
we also support the iTunes Music Store URL feature for AIM, thanks to Evan, but
we don't actually use it anywhere in Pidgin or Finch.

Given that we now have _proper_ status message support in our MSN plugin, some
of us who have objected to exposing the ability for outside modification of the
Friendly Name may feel less strongly about it.  I, in fact, have stated on
numerous occasions that I would no longer object if MSN status message support
were ever implemented.  I imagine we'd prefer to wait a couple releases before
allowing this, just to (hopefully) ease *our* users and plugin developers into
not abusing the Friendly Name, but anything's possible.  Of course, any change
in this respect would require being protocol-agnostic.

> Some of the things I think might not work correctly in msnp15:
> 
>  * http method

There were some changes today that probably help HTTP method functionality.  I'm
not sure exactly what they entail, but the commit message made it sound
important.  The HTTP method in general could probably use some in-depth TLC, but
Stu, Elliott, and Ka-Hing probably would know better than I.

>  * contact list handling, specially with the "Individuals" group

It's my understanding that the "Individuals" group is somewhat difficult to deal
with on anything newer than MSNP9.  Are there any specific tricks to managing
this, given that libpurple doesn't currently (and to my knowledge doesn't intend
to) support buddies that are not in a group?

>  * slow connection handling

This seems to be a problem in more than just MSN, depending on how crappy the
connection is.  There is certainly some room for polishing.

> A nice feature of msn-pecan is that it reports errors more properly
> "Unknown error: 606" (command errors). "Parse error" (http parsing
> errors) vs "Uknown Error". I've implemented this only on the
> notification server, but I plan to do the same in the switchboard
> server too. This would make it easier to track down errors.

More meaningful errors are good, but I'm of the opinion that (if they don't)
detailed errors should go to the debug API for appropriate handling instead of
being directly presented to the user.  In that vein, libpurple in general
probably could handle some more verbose debug logging in a number of places.

> Moreover, msn-pecan implements the most wanted features: #1 personal
> messages, #2 oim read support, #3 fast file transfers. While trying to
> fix long-standing issues, emulating slow connections, and injecting
> fake random errors. Seriously, there's people that plainly can't even
> connect.

I believe you've mentioned previously that the "fast" (i.e. peer-to-peer) file
transfer support doesn't work in all situations.  Is that still the case?  As
I'm sure you've discovered, this is difficult to get right thanks to NAT,
firewalls, etc.

> It's tempting to fall back to the default belief that msnp15 is better
> than msnp12, and that an official protocol plugin is better than an
> "alternative" one, but IMO the only things that should be considered
> is:
> 
>  * Is it stable?
>  * Does it provides the features users want?

I'll grant that fast file transfer is a feature a LOT of users want.  It's a
perfectly reasonable and understandable desire, even though I personally
couldn't care less about file transfer support in an IM client.

That said, is that support worth the necessary effort to use an alternative
plugin?  In Adium's case, this effort is put forth by the developers, so
naturally the answer is "yes" in that case when looking *only* at users.
However, I think that even though Adium is far more user-driven than Pidgin,
it's still worth the developers exploring if it's worth their time--their time
*is* finite, after all.  It's still certainly possible to implement peer-to-peer
file transfer methods in the so-called "official" libpurple plugin, even if said
support is not a priority to us.

Either way, I trust Evan and crew to make the decision they think is best for
Adium and just wanted to shed a little light on a few areas and further the
discussion.

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080714/870750a8/attachment.sig>