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

Gary Kramlich grim at
Sun Dec 30 00:10:57 EST 2007

Hash: SHA1

Felipe Contreras wrote:
> On Dec 24, 2007 8:43 PM, Gary Kramlich <grim at> wrote:
>> 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 :)

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

> Why would I want to go trough such painful and unfruitful process again?

Well, I don't even know if I was around for this, so I don't feel
"qualified" to comment one way or the other.

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

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

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

> Best regards.
> P.S. Any reason why this is not on the mailing list?

Because icedove decided not to include the list.  Aside from that I
don't know, but this thing (icedove) is all sorts of broken and removing
my filters and stuff.

For those of you that are going to tell me I don't know how to use email
(elb i'm looking your way :P), I didn't snip as much as I normally would
since I somehow missed sending this to the list.

- --
Gary Kramlich <grim at>
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the Devel mailing list