[Adium-devl] MSNP15 in Libpurple

Tue Jul 15 14:27:43 UTC 2008

On Tue, Jul 15, 2008 at 4:57 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> 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.

All this can be implemented in msn-pecan quite easily, I just
implemented what users really where eager for. The rest doesn't seem
to be a priority for them, so I won't bother to do it right now.

> 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.

I don't like your patronizing of users, but that's just me.

>> 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.

I don't know, I'm not following that stuff anymore, but proper http
parsing is a little tricky, if you have a fast connection it's easy to
be lazy and expect all the relevant information to be in the buffer,
and considering the bug I found in your command parsing I wonder if
there are similar or worst bugs in the http parsing. In any case,
handling redirection and http proxy tricks are also things to
consider.

Not that msn-pecan is doing a superb job, but the plan is to integrate
all the http stuff to reduce the number of issues. [1]

I doubt you have any further plans considering the improvement of the msn prpl.

>>  * 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?

I went one by one trying the different cases, normal and corner until
it was working correctly.

Stu and I had disagreements on how it should work. He thought the
"Individuals" group could be completely emulated as a normal group,
and I disagreed. So I bet you will have issues when having somebody on
the "Individuals" group and other group(s).

>>  * 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.

I mean, crashes and parsing errors.

>> 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.

Exactly, but in the meantime propagating errors prepares the design
for more useful errors. And makes it easier for the users to report
issues (they might not need to submit a debug log).

>> 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.

I meant, the particular portion of the p2p file transfers that I
implemented. Probably more than 90% of situations could work
automatically once everything is in place.

>> 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.

The point is not what's possible to implement in which implementation,
you can implement everything everywhere.

The point is that msn-pecan is listening to the users; not only
acknowledging which are the most wanted features, but implementing
them.

> 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.

I think the idea is that for 1.3 msn-pecan or msnp15 could be used,
and msnp15 (the official one) will be used for later versions.

At some point I thought msn-pecan wasn't going to be ready for 1.3,
but now I think it is. So before comparing it to msnp15 I think 1.3b8
should be considered.

Best regards.

[1] http://thoughtpad.net/alan-dean/http-headers-status.png

-- 
Felipe Contreras