msn-pecan now has direct connection support (fast file transfers)

[Felipe Contreras]

On Dec 29, 2007 11:10 PM, Gary Kramlich <grim at reaperworld.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Felipe Contreras wrote:
> > On Dec 24, 2007 8:43 PM, Gary Kramlich <grim at reaperworld.com> wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Richard Laager wrote:
> >>> On Mon, 2007-12-24 at 15:04 -0600, Gary Kramlich wrote:
> >>>> Right, he's working on code that we want.  This has to work both ways,
> >>>> otherwise all we do is piss each other off.  Which I think has been
> >>>> clearly displayed here.
> >>> If you're talking about other than this thread, I don't really care. If
> >>> you're talking about this thread, I hope you're not talking about me.
> >>> You know my love for the idea of a distributed VCS. I think most of the
> >>> advantages are lost when people start using separate DVCSes. This is why
> >>> I seconded the Monotone suggestion. We adopted a DVCS at least in part
> >>> because it made this sort of thing easier, so I don't see how we're not
> >>> doing our part there.
> >> I'm talking about our (the pidgin team's) behavior in general.  In this
> >> case we have someone who is writing code that we could benefit from, and
> >> has been brought to our attention.  Why are we alienating him?
> >
> > In my experience Pidgin is heavily biased towards the protocols the
> > main devs use (not MSN). And that's quite funny, considering MSN is
> > one of the most used protocols, if not the most, in the world.
>
> I see this argument all the time, I'm still looking for numbers ;)
>
> > As long as the developers avoid using the features most of their
> > potential user-base want/need they won't be able to understand why
> > they (the users) want them.
>
> I don't think it's a misunderstanding of why they want them, so much as
> it's a why are they so addament about them.
>
> > Take for example personal messages, which are not the same as away
> > messages. Pidgin devs never really understood them, and now we have
> > whole sites devoted to them (twitter, jaiku), and even Facebook
> > supports them. AFAIK even the MSNP15 prpl is implementing personal
> > messages as away messages.
>
> I'd call this more of a quote, but yeah, I've seen plenty of people use
> them, but since I've never used the official msn client, let alone have
> any msn buddies, it's not something I find that useful for me myself
> when status message get the job done for me.  That doesn't mean I'm
> against implementing them, but this sort of thing, at this time is
> difficult to abstract out.  On a side note, I don't think facebook is a
> good example, since you can't really be "away" from the site unless
> you're not logged in :)

That's why I'm not talking about away/status messages, but personal
messages. Something that doesn't have anything to do with the current
status.

> >> Aside from that, we are not infallible.  We chose to use monotone.
> >> Quite a few of us even have experience with tailor.  Why in the hell
> >> would we demand/strongly suggest, that someone who is comfortable using
> >> a different SCM, use the one we do when we are quite capable of doing
> >> the leg work we're already familiar with?
> >>
> >>> With regard to hackiness... Felipe has said numerous times he's going to
> >>> do things the wrong way because it's easier. I don't see anything wrong
> >>> with suggesting they be done correctly. I certainly wasn't trying to be
> >>> abusive and if that's what I sounded like, I apologize.
> >> I won't condone hacky coding.  I myself never check in a hack unless
> >> it's the only way possible.  However, there are two types of developers
> >> here.  Ones looking for instant gratification (IE: hacks are okay to get
> >> the job done) and others that don't mind taking the extra time.
> >
> > In the past I tried numerous times the "right way" and still I was
> > alienated. Take for example my work on the presence stuff; it was
> > quite ready years ago, made things much easier for the MSN prpl, and
> > not hard on other prpl's, but KingAnt didn't like the internal design
> > and that was it.
>
> I find it hard to believe, that out of all the developers, Mark,
> wouldn't give guidance.

Of course, he gave me guidance about how to do it the way he though
was the proper one.

> >> I'd say we (pidgin) have an interesting balance of the two.  And while
> >> they may drive each other nuts, they compliment each other well.  The
> >> instant gratification developers drive changes, the slow and steady
> >> developers keep things stable and scalable.  Of course this balance
> >> falls apart when communication breaks down.
> >>
> >>> Let me try this again:
> >>>
> >>> Felipe, I personally think it would make merging code easier for you if
> >>> you used the same DVCS as us. It would definitely make it easier for us
> >>> to bring your changes upstream, with or without changes. It's certainly
> >>> your choice which tools you use, though. If you want tailor setup, let
> >>> me know and I'll see if I can find some time for that.
> >> Right here you've shown a knowledge of monotone, if you're going to help
> >> him through it when he's not interested, why not just do it yourself?  I
> >> realize time is a factor, but time has been used as an excuse so much
> >> that it really has lost all meaning.  Honestly, how much more time is it
> >> going to take to walk someone else through something you're already
> >> familiar with compared to you doing it for them.  If there's a genuine
> >> interest, by all means.  If not, then let it go, it's not going to happen.
> >>
> >>> Regarding hacks... I would recommend you let us know where you're
> >>> feeling the need to make hacks and we'll see if we can fix those.
> >> I agree completely with this.
> >
> > IMHO the prpl API has a totally bad design, but let me try to focus my
> > complaints.
>
> I agree, and this is why I need to find more time to dedicated to
> gobjectification.  However, that probably won't come until after march
> since I'm trying to get guifications3 to a state where I can get atleast
>  one GSoC student this summer.

We share the same opinion then. GObjectification of libpurple is
something that must be done.

> > Split alias/nick, and local-alias/remote-alias. Actually a local-alias
> > doesn't follow Pidgin's principles; if the protocol doesn't support
> > aliasing why support it in the client?
> >
> > If that simple change gets implemented then I'd have a little hope of
> > change... I'm not holding my breath.
>
> Doing something like this is a bit harder since libpurple actually
> exists and is versioned correctly.  Basically, this would require a
> major version bump, but as I've stated on many occasions, our users are
> going to expect more than just some api changes for a major version :)
> However, I am completely for this kind of behavior.  I proposed a while
> ago, and don't recall getting any strong feedback one way or another,
> for making PurpleBuddy an abstract class (this gets back to
> gobjectification).  That then puts the control of protocol specific
> ideas (in this case msn) with out having to, for lack of a better word,
> pollute, the core.

I understand, that's why it's not good to have non-extensible API.

> >>> Regarding MSP15 vs. MSNP9... My *guess* would be that eventually MSN
> >>> will discontinue the older protocols, so it seems to me that it would be
> >>> better to develop against the MSNP15 code. Are there particular problems
> >>> with that code which are preventing you from working with it?
> >> Mind you I know squat about MSN, but maybe theres some magic we can work
> >> to have both versions share as much code as possible, similar to
> >> AIM/ICQ?  Also, I can't imagine they'd just turn off an old version of
> >> the protocol when, I suspect, that the newer versions of the client
> >> won't work on older versions of the OS.  Of course that's just
> >> speculation, as well as the idea that the eventual turning off being in
> >> the near future.
> >
> > Yes, large parts of the code can be shared, the only major things that
> > change are the buddy list handling and login process (which now
> > require SOAP), AFAIK.
>
> That'd be awesome if we could make this happen.  I don't mean actually
> allow 3 prpls for the same protocol, but maybe with a configure argument
> or something to select the most stable one while still allowing a
> fallback or something.

That would probably require some code reorganization in order to split
the different layers of the MSNP, something I'm already planning for
msn-pecan, but I won't touch the MSNP15 code.

Best regards.

> - --
> Gary Kramlich <grim at reaperworld.com>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHdyhhdf4lmqisgDIRArENAKCYplxPD8C7cj0ZSrvg1Yc6sH/PKQCgoLe0
> f9th801BbStyCb6giLQFukc=
> =hFUw
> -----END PGP SIGNATURE-----
>

-- 
Felipe Contreras