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

[Ka-Hing Cheung]

> Felipe Contreras wrote:
> > 
> > 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.

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

It's certainly not funny that we tend to work on things that we use,
consider that most of us don't get pay to work on things we don't use.

I know lots of people want a newer msn prpl to support personal
messages, but to me the more important feature is offline message
support. It's not a big deal to miss an available message that wasn't
directed specifically at you, but missing an offline message when the
other side has no idea the message has gone to a black hole is
considerably worse. As such, I see no reason to work on a protocol
version that doesn't support (at least receiving) offline messages.

Does that make me not understand personal messages now?

(I don't even know where you got that idea from anyway, most of our
other prpls support some sort of available/away message)

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

Pidgin support many things that are not supported by the protocols, take
adding a chatroom to the buddy list for example. I don't see a reason
not to do that given the feature is useful. I think local alias is an
example of a useful feature.

(snip all the other discussion about API changes)

We have a system in place to change API, if we need to change some API,
then we change it. I don't see a need to bundle some exciting features
with every major version bump, provided that we give some time to
stabilize things.

Those who wish to influence API change can discuss/work on those
changes, those who don't shouldn't be surprised when things change (or
doesn't change) underneath them. I have no idea whatever unpleasant
experience you've had, but that's not relevant. If there's still
anything you want changed, submit a patch and keep pushing it until
someone is convinced.

-khc