[Adium-devl] MSNP15 in Libpurple

Marcos Saraiva msaraiva at gmail.com
Tue Jul 15 20:34:50 UTC 2008


Will be implemented, but it's not, right now. MSNP15 already provides OIM
support. I have nothing against msn-pecan, but the current libpurple's
MSNP15 is much more useful, IMHO (solely because of OIM).


Marcos Saraiva

On Tue, Jul 15, 2008 at 12:42, Devid Antonio Filoni <devidfil at gmail.com>
wrote:

> 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
> >
> >
>
> _______________________________________________
> 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/d91200cb/attachment-0001.html>


More information about the devel mailing list