[Adium-devl] MSNP15 in Libpurple

Tue Jul 15 15:42:46 UTC 2008

OIM (read only support) will be implemented very soon in msn-pecan as
you can read at:
http://code.google.com/p/msn-pecan/issues/detail?id=14
After this will be implemented direct connection file transfers (not
supported in libpurple) as you can read at:
http://code.google.com/p/msn-pecan/issues/detail?id=35
Also with msn-pecan we have some nice and *useful* features as you can
read in the previous emails.
So I don't think there is a problem of features.

Devid Antonio Filoni

2008/7/15 Marcos Saraiva <msaraiva at gmail.com>:
> 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
>
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
>
>