[Adium-devl] MSNP15 in Libpurple

Tue Jul 15 15:19:14 UTC 2008

You can implement them, but the fact is, they're not there yet. OIM is a
must these days for anyone that uses MSN. I've been using Dimuxxx builds for
about a month, and i must say, they made me finally power down the VM i had
running Windows on it, so i could use the official MSN client.

I had high hopes that MSNP15 would be included in 1.3

Marcos Saraiva

On Tue, Jul 15, 2008 at 11:27, Felipe Contreras <felipe.contreras at gmail.com>
wrote:

> 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
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080715/8b8d8387/attachment-0001.html>