Pidgin News
August 28, 2011 03:44 PM by John Bailey
Well, it's been about forever since I last bothered to post anything here. Since my last post, we've released several times, introducing and fixing a bunch of bugs. Now, however, we're shifting our focus to new development of a sort that we don't do often—compatibility breakage and big internal changes. This means that our main development effort is now in working toward Pidgin and libpurple 3.0.0. I'm going to try to explain some of the work going on for the benefit of anyone who reads my ramblings, so here goes.
Versioning
First of all, there seems to be some confusion about how Pidgin and libpurple version numbers work. I'd like to try to clear some of that up.
Pidgin, Finch, and libpurple use what's called “
Semantic Versioning.†That is, each part of the version number has a particular meaning for users and developers. We chose this scheme to assist plugin developers in knowing when significant changes would require effort on their part to maintain compatibility with current Pidgin and/or libpurple versions. It also helps our users by letting them know when their existing plugins will stop working. So, how does this semantic versioning work? Let's look at the format of our version numbers and find out.
Pidgin, Finch, and libpurple version numbers have three components, separated by dots. At the time of this writing, 2.10.0 is the current version number. These components are called major (currently 2), minor (currently 10), and micro or patch (currently 0). Let's look at what each means.
Major: the major version doesn't change often. The last time we changed it was in 2007 with the release of Pidgin 2.0.0, and before that was in 2004 with 1.0.0 when we started using semantic versioning under our previous name. Whenever this number changes, we've made changes to Pidgin, Finch, or libpurple that break compatibility with every UI and plugin that currently exists. Usually this means that we've removed something from the API exposed to plugins and UI's, or that we've changed something about a function (its name, arguments, return type, or the header file it's in). Sometimes plugins or UI's can just be recompiled when this happens; other times they need maintenance to become compatible with the new release. Additionally, the major version never decreases. It will always increase when it changes. Minor: the minor version changes more frequently than the major version, but generally less often than the micro or patch version. Whenever the minor number increases, we've added things to our API that do not break compatibility with existing plugins or UI's. A prime example of this is adding the voice and video support we added in 2.6.0. We added a bunch of stuff to the existing API, but didn't change anything that would cause a break in backward compatibility with existing plugins and UI's. When the minor version decreases (gets set back to 0), it means that the major version has changed, and the whole cycle starts over. Micro or patch: The patch version changes with almost every release. When this version increases, it means that we haven't touched API at all; instead we've done nothing but fix bugs or add small features that don't affect compatibility with plugins or UI's. When this version decreases (gets set back to 0), it means that the minor version has changed.
Related to all this, and important only for plugin and UI developers (so skip this paragraph if you're not a developer!), is the behavior of the
PURPLE_VERSION_CHECK macro. Many developers expect
PURPLE_VERSION_CHECK(2, 5, 0) or similar to expand to a statement that evaluates to
1 or
TRUE in the case of building against libpurple 3.0.0. This, however, is
not the case. Because our major versions are incompatible with each other, we have intentionally written
PURPLE_VERSION_CHECK to fail if the major version is not an exact match. We understand this can be confusing and inconvenient, and we sincerely apologize for that, but we're not going to change it.
What all this means is that if the first number (major version) changes, you're going to need to update your plugins when you upgrade Pidgin, Finch, and libpurple. If the second (minor version) or third (micro version) numbers change, it means you need to upgrade Pidgin, Finch, and libpurple, but your existing plugins will still work. No matter what the Pidgin, Finch, and libpurple version numbers are, you should always be using the newest version.
Structure (“structâ€) Hiding
This paragraph is for those who aren't programmers. Feel free to skip it if you don't care about it. Pidgin is written in the C language. C has a type system, which means that if you declare a variable (imagine this as a box somewhere in your computer's memory) you can store only one type of data in it. A structure, or struct in C parlance, is a type made up of other types arranged sequentially. This is pretty easy to picture if you think of Lego blocks--stack a red block, a blue block, a green block, a yellow block, and a white block on top of each other and connect them together and you now have a structure made out of Lego blocks. It's pretty similar in C, except that you're telling the compiler to assemble something out of sequential boxes of memory instead of little plastic blocks.
Pidgin uses structs everywhere. We use them to represent things like your buddies, conversations, accounts, etc. Currently in Pidgin 2.10.0, most of the structs are in the public API—that is, anyone can directly access the members of the structs and do whatever they like. This is all fine and well, but it means that if our code changes such that a particular struct needs to grow significantly by the addition of new members, we can't always do that without breaking backward compatibility. (Yes, we included padding in a number of our structs, but we've burned through the padding in several of them, and although there are ways to work around it, I and a few other developers don't like them.) It also means that if we discover, for example, that switching the order of members in a struct allows the compiler to improve its optimizations or if we think a different order makes more logical sense for those of us reading and maintaining the code, we absolutely can't do this without breaking compatibility. We also can't rename members of structs for the same reason—it breaks compatibility with existing plugins, UI's, etc.
Because having these structs in the public API limits us so much, we're striving to hide as many of them as possible. By hiding, we mean that we're removing the struct definitions from the header files and moving them to the .c files, thus making them private. Plugin and UI authors will still be able to reference the “objects†with pointers, passing them to functions and operating on them with the appropriate sections of our public API, but no longer will the members of the structs be directly accessible outside of the .c files that define the functions that interact with them. For example, we have a PurpleRoomlist struct in libpurple/roomlist.c and libpurple/roomlist.h. For 3.0.0, the struct definition is in roomlist.c; thus the individual members are not directly accessible outside roomlist.c, even in other parts of libpurple. This “hiding†of the strcuts allows us significant internal flexibility in each file to modify the struct as we see fit.
Clean-Slate API Documentation
Because we generally change so much each time we increase our major version number, the API documentation can get a bit confusing if we keep doing
@since tags and whatnot in our doxygen documentation. Our general overall feeling is that we prefer just starting with a clean slate at each new major version. This means that each time we do a new major version, all existing
@since tags will disappear, any functions marked as
@deprecated will be removed, renamed, or replaced as described in the
@deprecated statement, and so on. We realize this decision may make some things more difficult for some plugin and UI authors, and we apologize for that, but our aim is to have overall cleaner documentation for everyone.
Merging of Old Projects
Over the years that we've participated in Google's Summer of Code program, we've accumulated a number of branches that have been sitting for quite some time. Most of these need some form of TLC and integration work. We want to try to incorporate at least some of them into 3.0.0 so we can finally benefit from the fruits of the students' labor. Most notably, we've been talking about merging the webkit integration branch into what will become 3.0.0. Eventually, this would allow the support of Adium's message styles, although it may not happen right away.
Another project of notable interest is some of the logging changes that went on in a previous Summer of Code project. One of our new Crazy Patch Writers took some of that work and made some progress on it; we don't know if this will make it for 3.0.0 or not yet, but it would be nice to have some of the features, such as non-blocking log writing.
Other Changes As Wanted
We may decide to make other changes since a major version change gives us the opportunity to break so much. There have been a number of ideas floated, ranging from supporting that XDG directory spec that I can't stand to doing away with the xml files in .purple and replacing them with something else (with what, in particular, has not seriously been discussed). There is a whole range of possibilities of things we could do for 3.0.0; it's just a matter of one of us wanting it and sitting down to write it.
So everyone should stay tuned, as we'll be making more and more changes over the course of the 3.0.0 development cycle. We don't yet know when we'll be releasing 3.0.0—this is another one of our famous “when it's ready, and not a minute before†time frames. We do know, however, that it will change a lot!
August 04, 2011 07:49 AM by Mark Doliner
I wrote a crummy tool that displays the current DNS SRV records for a given XMPP domain. After writing it I discovered that Olark has already created something similar.
My tool attempts to do some really basic sanity checks and warns if it sees problems. If you think of something that it should check for but currently does not, please let me know! And please let me know if you notice any problems or have other suggestions.
March 12, 2011 09:13 AM by Mark Doliner
Pidgin/Finch/libpurple/Instant Messaging Freedom, Inc. didn’t apply to be an organization in Google’s Summer of Code (GSoC) this year.
Why not? The short answer is that I didn’t feel we had enough developers willing to mentor students for it to be worthwhile.
The long answer is a little more complicated. I feel very lucky that Pidgin has been able to participate in GSoC for the previous 6 years. GSoC is an amazing program and it gives me a warm feeling that Google has consistently funded it, and I hope they continue long into the future. I think I’m a better person for having mentored some students and for having been our organization administrator a few years.
Pidgin has certainly benefited. Heck, Finch itself was a GSoC student project. And the developer went on to be an integral part of our development team. Other benefits: Our UPnP implementation for peer to peer connections. SIP/SIMPLE/STUN. A D-Bus interface. Performance improvements. MSN, ICQ and Yahoo! maintenance. The MySpace protocol plugin. Our certificate manager.
But mentoring students does take time. Five hours per week per student is a reasonable approximation. Some students need less guidance. Some students are so productive they need more help, having their code reviewed, getting feedback on implementation ideas, etc. Reading through and ranking all the student applications takes time. There’s also a mid-term and final evaluation survey that must be filled out. The time required for all this isn’t particularly unreasonable, but many of us developers have very little time to start with.
I tried to get a verbal commitment from some developers this year on whether they’d be able to mentor and the response was pretty limited. In general people expect to be pretty busy this year, and it didn’t seem appropriate for us to commit to GSoC when we may not be able to give our students the level of attention they deserve.
And so it is with a sad heart that I decided not to submit our application this year. It seems likely we’ll apply again in 2012. Also, please don’t get the idea that we don’t want contributions—we love patches and new contributors!
February 23, 2011 08:50 PM by John Bailey
Over the last couple hours, we've had nearly everyone and his/her brother in #pidgin asking about connections to AIM causing a certificate prompt. The specific prompt is for bos.oscar.aol.com. The issue here appears to be that AOL has let the certificate expire. Because our certificate validation is more strict than some other applications, Pidgin users will get this prompt at every connection until AOL installs an updated certificate.
To resolve the prompt, you can make one of a couple choices. You can choose to trust that the connection is fine even though the certificate is expired and click Accept, or you can take the safe route and click Reject until AOL replaces the certificate.
To reiterate, this is not a Pidgin problem, but an AIM server problem.
February 04, 2011 10:36 PM by John Bailey
In an
earlier post, I discussed how to take advantage of Pidgin's "saved status" feature. After seeing some recent confusion in #pidgin about our status features, I decided it would be a good idea to give a quick overview on how to take advantage of a feature I never use--creating statuses (including complex statuses) from the status selector on the buddy list window.
The status selector feels like it's been around forever. Prior to this, we had a rather horrible interface to "status" whereby you could either globally set all accounts to "away" or go to each individual account and configure a given status (away, do not disturb, vacation, etc.). All this was done via a single menu. For those of you who don't remember it, let me just say that it
sucked. Someone (I think it was Sean Egan) threw that whole UI out the window and came up with the current status selector that reminds me a lot of the old Windows ICQ 99 client that had a pretty similar status selector. Ours is a bit more sophisticated, though.
The simple use of the status selector is fairly obvious--pick a status and type a message. In fact, this is what the majority of our users do when they change statuses. This is what is called a transient status. What most people don't know, however, is that you can create complex statuses, such as having your MSN account set to "Busy" while your AIM account is set to "Invisible." Let's give a quick example.
I have a number of accounts in Pidgin. Let's say I want to have my pidgin.im XMPP account set to "Available" but the rest of my accounts set to "Away" to create a simplistic scenario that's really easy for me to snag a screenshot of. To do this, I'll go to the status selector and select "New status..." like in this picture:
Then I'll see this window, where I've already gone and entered a title for the status. This is the name you'll see in the status selector and in the middle section of the status selector's menu. If I wanted a message to go with the away status, I'd enter it here now, as well.
Since I want most of my accounts to be away, I'll leave the "Status" selection as "Away." As you can see, I have my mouse pointer over "Use a different status for some accounts," which when expanded will allow me to set statuses for individual accounts, like so:
I found my pidgin.im account in the list already, so I'll check the box in the "Different" collumn. That brings me to a new window:
Now I want my pidgin.im account to be available, so I'll accept what I see. If I wanted a message here, I'd type it in the "Message:" box. When I'm happy with what I have, I'll click OK. Notice that the "Status" column in the previous window changes to reflect what you selected for the individual account.
Since I'm happy with what I have, I'll now click "Use", which applies the status. If I wanted to make this a saved status that is saved permanently, I could click the "Save" button or the "Save & Use" button if I wanted to also immediately apply it when saving.
That's all there is to it!
Last weekend was the GSoC Mentors Summit. As a mentor for the Pidgin, Finch and libpurple project, I attended for the first time this year.
It was pretty interesting and a lot of fun, but I have to say I didn't really feel like much of a geek there! Everyone's either got an iPhone or a Droid, and they've all done awesome stuff. Can you say you've worked on WordPress, used by millions of websites, or Apache, serving even more websites, or RTEMS, running several space exploration instruments and other consumer products, or who knows what else?
Nevertheless, it wasn't like I was totally unknown. There were quite a few people who use Pidgin, even one or two using Finch. Oh, and some Mac users using Adium (using libpurple), too.
The flight was fine, but the weather was a bit disappointed. It would have been nicer to explore a bit more, but at least I got to eat a ton of chocolate. I'll try and write a longer re-cap later.
I have just pushed the revision that merges my MSNP16 and SLP branches to the main development branch in pidgin. I'm very happy to have this branches merged since they represent almost all the code I have been writing on the last year.
Yes I have started coding MSNP16 support almost a year ago and it took a lot of effort, reverse engineering, debugging Wireshark dumps and a lot of pidgin debug logs to get it working. That is a lot of time!
It is true that the MSNP16 code was almost complete when I started my SoC work but I though it would be better to start the SLP rewrite over the MSNP16 branch to be able to easily test both codes at the same time and try to get it in a better shape before merging it to i.p.p.
I know I have announced this merge like two weeks ago, but you know, I wanted this merge to be followed by a reasonable "beta" testing before being released and at that time it got that we had an security issue and needed to release 2.7.4. Once it was out, there were some ICQ issues that needed a quick release to fix that bugs, so we got a 2.7.5. Now I was able to merge and get a normal release cycle to get beta testers to find bugs in this new and nice code.
I hope this code will fix more issues than it brings up, specially the ones related to data transfer. Since most of the code on this area have changed due DirectConn and SLP-rewrite, I guesss it would be a good idea to review and close most of the related tickets since the traceback and debug output would be really useless now. Yei for smashing tickets!
I hope you all like 2.7.6 when it get released!
October 26, 2010 02:06 AM by John Bailey
Well, by now it's obvious to the world that I kicked Pidgin 2.7.4 out of the nest last week. Although that release included some nice new features for ICQ users, lots of bug fixes, and some remote crash fixes, it's not without its share of problems. Those problems are producing a bunch of duplicate tickets for us to deal with, so I thought it might be a good idea to post about them here just in case anyone bothers to read my rambling.
The first problem is the AIM/ICQ chat bug. When using a multi-user chat on AIM or ICQ, no messages can be sent. You'll get an error stating your message was too long. This was an unintended side effect of merging the work of one of our Summer of Code students. Ivan accidentally removed a line of code that he shouldn't have. Yes, you read that right--a single line of code. Apparently it was pretty important! Ivan restored that line and things will be working as they should in 2.7.5 when we release it.
The second problem is an old one that's come back with a vengeance. This one is an ICQ issue where messages that contain
disappear because they're treated as HTML tags. This seems to be specific to combinations of Pidgin and other non-official clients. Pidgin recently gained some new ICQ protocol-level features related to formatted messages; some non-official clients, including older versions of Pidgin, don't handle it gracefully. At this point, we've done all we can do about it; the other clients will have to step up and make fixes to handle the messages correctly now.
The next problem is another wonderful ICQ encoding bug. I'm not sure if this one is a side effect of Ivan's work or not, but Ivan did do a lot of work on encoding problems on ICQ. We all thought things were improving, but apparently there are still a few odd cases (and a crapton of stupid ICQ clients that should be purged from existence) in which our handling of encodings just isn't quite right. We're aiming to have this fixed for 2.7.5, but it's not quite done yet.
Is it obvious I wish ICQ would just disappear immediately and permanently?
The last "big" problem that seems to be cropping up is a crash related to MSN file transfers. When using direct-connect file transfers, somewhere along the line we do something stupid internally that causes a crash. We thought we had it fixed for 2.7.4, but alas it still exists. We're looking into it and hope to get it fixed soon. In the meantime, it's pretty easy to prevent the crash--edit your MSN account and turn off the direct-connect file transfers. It's an option on the advanced tab of the account editor.
At any rate, since we know about these bugs already, please, please, please DON'T open new tickets about them!
As you know I have been working on a refactor for the SLP code on the msn-prpl for libpurple as part of my Summer of Code. Before I started this project I have been working on adding support for "Multiple Points Of Presence" which are part of the MSN Protocol 16 (MSNP16).
Since by the time I started the SoC the msnp16 code was almost complete, I started to refactor the SLP module over the msnp16 code. At some time in the process of the refactio I got an ugly crash from one of the features of MSNP16, the P2P version 2 which uses a different binary header for SLP transfers than the one used before. This bug was caused by some clients not paying attention to the capabilities we expose, we clearly say we don't support P2P V2. To avoid this crash I have disabled MSNP16 in the SLP branch.
I have been testing the SLP code for a while with the MSNP16 feature enabled and it looks stable to be merged. The crash has gone, there are some minor changes that must be done, specially UI stuff, the new SLP stack have no known bug.
I have updated the SLP branch with the latest changes from the MSNP16 branch, so this branch [1] have every work waiting to be merged to pidgin's main development branch. This was the first step to get it merge-ready. There have been some testing form some of our closest geeky-friends and now I think it's ready.
My plan is to merge the SLP code with the MSNP16 feature enabled the next week to im.pidgin.pidgin. I ask everyone interested in this features to test it before it get to main branch so we can have a softer merging process.
[1] im.pidgin.soc.2010.msn-tlc
Note: This post was wrote 2 months ago and never published, my bad.
After some bug squash, I finally got p2p transfers working. I have tested sending and receiving custom emoticons and display pictures, smallers than the SB limit and bigger than that. They just work ok.
I guess I need to test some file transfers before thinking my work is done, I also have some cleanup that I want to do but I guess I can declare that the new stack is working nice and is very close to be merge ready. I'm really glad to say so.
So, it seems the Facebook has finally added support for logging in to their Chat via XMPP. This is, of course, awesome so people stop asking about it, but also terrible since it took them so darn long. That meant a lot of horrible hacks just to get it working in the interim. (No offence Eion, I just mean the scraping, not the code.)
This announcement comes straight from the developer blog. You need to have set up a username (which you can check here). Casey's blog has all the screenshots you need to figure it out. The only downside is it doesn't use encrypted streams.
The biggest problem, though? Having to organize a few hundred buddies into their correct contacts.
June 26, 2010 12:37 AM by John Bailey
As many of you Yahoo users out there know, Pidgin 2.7.0 and 2.7.1 introduced a challenge for you. In certain proxied environments, many of you can't connect. Quite frankly, (mostly) it's my fault. Let's start by explaining what I've done.
In Pidgin 2.7.0 I made some seemingly innocent changes to the Yahoo protocol plugin that I thought would magically make some problems go away. These changes make us mimic the official Yahoo client better. Very early in the connection process (in fact, it's the first step), the official clients request a specific URL from a Yahoo web server. The server's response tells the client what messaging server to connect to. The client reads that address and connects to it, then goes along its merry way. So I made our Yahoo plugins do this, once I determined the correct URL's for both Yahoo and Yahoo Japan. Everything was great when I tested.
But there's my mistake--I tested it. I don't run a proxy server--I'm an IT nerd, but I'm not that much of an IT nerd. So, I allowed this to be released, not knowing there were problems in environments with restrictive proxies. It came back to bite me hard, as I backported this stuff to Adium's build of libpurple 2.6.something for one of their beta releases and several users started complaining about being unable to connect. Then we got a couple tickets of our own. At first, I was stumped, until a user who was willing to almost bend over backwards to assist us came along.
This user worked in an environment where two separate proxy servers were in use. One handled HTTP and HTTPS traffic and the other handled IM protocols. It took me quite a while to finally wrap my head around his problem, but once I did (with the help of my fellow developer Etan Reisner), I was able to start solving the problem. It turns out I actually had two problems on my hands, but at first it seemed like none of it was the fault of our code.
The first problem is that Pidgin allows configuring proxies in two places--the "Proxy" tab shown when editing an account and the "Proxy" tab in Preferences--but does not allow specifying what ports or services are handled by each proxy. This ordinarily isn't such a big issue, except that I went to the extreme of creating an option for Yahoo accounts to help some users with weird proxies that don't handle SSL at all. This option is used to determine whether to send an HTTPS request (like Yahoo uses for login) to the account's configured proxy or to the global proxy configured in Preferences. When I did this for 2.6.0, I created a new utility function for URL requests that allowed specifying the account the request was for. If the magic value NULL is passed to this function, the request will use the global proxy instead of the account proxy. This allows our proxy code to route the request to the appropriate proxy. Being the idiot I can be on occasion, I set all URL requests in the Yahoo plugins to use the account proxy server no matter what. This is where the user's problem came in--his IM proxy doesn't do HTTP at all. Once Etan and I agreed on how to fix it, I changed the SSL option I mentioned earlier to act on both HTTP and HTTPS requests. I supplied our user the test build. It still didn't work, but the debug log showed some interesting new info.
Again, it took some head-bashing to understand what was going on, and I still wasn't the one who figured it out. In the meantime, I decided to implement a quick hack to make users at least be able to connect temporarily while we figured out what was really broken in our proxy code. The quick hack was to implement a worst-case, last-resort connection to a previously known messaging server. Unfortunately, I could implement this only for Yahoo, not for Yahoo Japan, as the Japan network appears to no longer has a single canonical hostname by which to refer to the messaging servers. I am, however, positive that even on the regular Yahoo network, this hack will eventually break, which is why I resisted it in the first place. After a couple quick bugfixes brought to light by the user's further testing, we had a working fallback mechanism.
Once this was done, Daniel Atallah, one of our co-lead developers, realized that the second problem our helpful user had was our own proxy code's fault--for some stupid reason, we would never authenticate to an HTTP proxy if we were making an HTTP request on the standard HTTP port (80). Daniel implemented some quick fixes to make our URL requesting code behave better in these proxy situations, thus (we hope) finally solving this problem completely.
All these fixes will end up in Pidgin 2.7.2. We're not sure yet when we're going to release that, but we're hoping it's soon, as we have some fixes for other annoying bugs, such as the famous MSN direct connection crash.
Now, after reading all this, some of you might think, "Why don't they just use libproxy?" Truthfully, that's probably a good idea. There are two reasons we haven't done this yet. First, we looked at this over two years ago. At that time, we were led to believe libproxy didn't handle all the proxy types we did. We were corrected on that, but I, at least, missed that correction being posted. (Sorry, sometimes I'm blind, especially if something like that is buried in a flood of other ticket mails.) I suspect I'm not the only developer who did. Secondly, we're all creatures of habit. As the old saying goes, "if it ain't broke, don't fix it." Well, quite honestly, it's not broken for us as developers! Mainly that's because either we don't use proxies or any proxies in our way don't do any of the crazy stuff we ran into in this case. If it's not broken for us, we don't have much incentive to go hacking stuff up to support new libraries that solve problems we don't experience. I know that sounds like a lame excuse to a lot of you, and I can understand how it seems that way. But if we don't experience the problem, it's hard to test that we've fixed it, and we could in fact be making matters far worse for everyone else.
All this said, we probably should support libproxy. I've been thinking about how we could do this in a quick and effective manner, and so far I've come up with a few ideas that don't feel like they work very well. I think this is a perfect case where code should talk, or at least provide an example. So, I invite people who would like to see us support libproxy to write patches. Actively engage us on our development mailing list (
devel@pidgin.im), talk with us in
#pidgin on irc.freenode.net, or drop by our XMPP MUC (
devel@conference.pidgin.im). Or, do some combination of the three. I can't promise we'll be the most valuable resources during the process, but we do at least try.
Now supporting libproxy is one thing. Actually being able to do useful stuff with the information libproxy gives us is another thing entirely. Our actual proxy connection code is, shall we say, a bit sub-par. Quite frankly, it sucks, even ignoring the crappy configuration portions. While supporting libproxy is nice and may solve a lot of our proxy problems, I guarantee it won't solve them all. Ideas and patches to fix this are greatly appreciated too.
I look forward to hearing from those of you inclined to help!
Direct connections for MSN! What do I mean? Just take a look at the screenshot below.
What's that? You don't see it? Just take a look at how fast it's going. Yes, that's right; it's not a pitiful 10KiB/s, but about an order of magnitude faster.
It all started with this little patch on trac. But it required a lot of work to get it going. I must have made at least 60 commits just fixing things and getting it to cooperate with aMSN and the official client. I think it should be good now, but you can always disable it in the Account options. It even makes buddy icon and custom emoticon loading faster.
Anyway, I promised I would say something about 2.7.1, and here you go. Direct connections will be in 2.7.1. In fact, I'm just about to push all the revisions.
Have you ever started committing things in Monotone and then realized "This should probably go in a separate branch"? It's somewhat difficult to fix that. You can add a new branch cert, but the old one won't go away.
I wrote a little script based on a mailing list message I saw. It removes the old branch cert, and adds the new one, moving forward along revisions. It even changes merges with "the rest" into propagate messages instead. There are limitations, though. It only works with linear history (but if you've been working alone, that shouldn't be a problem) and it requires mtn 0.45 (since it uses the binary cert format.) Of course, it goes without saying that if you've shared any of your changes with someone else, then this is pointless (or you'd have to change everyone's database.)
It's pretty short. Make sure those SQL statements don't break up when you copy it.
#!/bin/bash
set -e
DB=db.mtn
KEY='someone@domain.com'
OLD_BRANCH='com.domain.main'
NEW_BRANCH='com.domain.fancy-stuff'
prev=
curr=$START
while [ -n "$curr" ]; do
echo "Changing revision $curr"
mtn --db=$DB db execute \
"DELETE FROM revision_certs WHERE hex(revision_id) = upper('$curr') AND name = 'branch';"
mtn --db=$DB -k$KEY cert $curr branch $NEW_BRANCH
parents=`mtn --db=$DB automate parents $curr`
if [ `echo "$parents" | wc -l` -eq 2 ]; then
# Fix a merge
echo "Fixing merge for $curr"
mtn --db=$DB db execute \
"DELETE FROM revision_certs WHERE hex(revision_id) = upper('$curr') AND name = 'changelog';"
other=`echo "$parents" | sed -e "/$prev/d"`
mtn --db=$DB -k$KEY cert $curr changelog \
"propagate from branch '$OLD_BRANCH' (head $other)
to branch '$NEW_BRANCH' (head $prev)"
fi
prev=$curr
curr=`mtn --db=$DB automate children $curr`
done
START=
0123456789abcdef
0123456789abcdef
01234567
May 13, 2010 11:40 PM by John Bailey
Well, I finally managed to kick Pidgin 2.7.0 out the door, as most of you are surely aware of by now. There are several important things to note about this release:
AIM and ICQ clientLogin issues have been resolved. You should be able to now use both clientLogin and SSL together. Our internal libgadu has been upgraded from something from the stone age to something much, much more current. This solves the issues that (primarily) Windows users had with not being able to communicate with new (> 17,000,000) Gadu-Gadu numbers. Our Yahoo and Yahoo Japan plugins now retrieve connect server information directly from Yahoo, just like the official clients do. This took me way too much time to implement, but I believe I've implemented a fairly stable and maintainable method to retrieve this information. During this process, I learned a lot about how Yahoo's authentication works and made some improvements there too that will make us look much more like the official client on the wire during authentication. ICQ now has X-Status support! It took far longer than it should have--I originally wanted this in for 2.6.0 but it was nowhere near ready. Minimum GTK+ and GLib requirements are now 2.10.0 and 2.12.0, respectively. This allowed us to drop some 3800 lines of code, much of which was the result of needing to bundle certain GTK+ widgets so Pidgin could function on platforms with ancient GTK+. This also makes use of many of glib's convenience functions much more convenient. The Windows installers have changed to be less obnoxious with respect to GTK+. We no longer install a system-wide copy of GTK+ and instead install GTK+ locally to the Pidgin installation. This may disrupt some GTK+ theming. The other big thing is that now, the default installer will download GTK+ and optionally the debug symbols (so there's no longer a special debug installer needed for crash reports!). There's also an offline installer that, while almost double the size of the default installer, I prefer to use. This offline installer includes GTK+ and the debug symbols. I prefer to call it the everything-but-the-kitchen-sink package (the kitchen sink in this case being spell checking support, which still must be downloaded).
Of course, any release I had a major role in is bound to have problems. I built the Windows installers this time around, and did not know that I needed to do extra work to make the online installer function. Thus, many of you complained (and complained, and complained some more!) that the installer didn't work. Even after Daniel fixed this for me, we still saw complaints. If the online installer does not work for you, try the offline installer. I tested the offline installer and it worked for me. I forgot, however, to test the online installer. I was more interested in getting the release out in order to (I thought) minimize complaints.
Additionally, after I cut the tarballs for 2.7.0, several bug fixes rolled in that will be delayed until 2.7.1. Among these are a couple minor annoyance fixes for MSN and XMPP. And today fixes for more bugs rolled in, including two for Bonjour and a fix for the taskbar entry (window) flashing on Windows. I plan to push out Pidgin 2.7.1 in a couple weeks to resolve these, and hopefully more, problems.
In the mean time, enjoy!
So it seems like I only post about minor releases (as opposed to micro), but I promise that I'll definitely say something about 2.7.1.
Anyway, Pidgin 2.7.0 should be released pretty soon now. You may or may not know that the release versions are dictated by API/ABI requirements. A minor release means we've added API. I wouldn't say there are tons of new user-visible features in this release, but definitely some developer-related things.
Most importantly, we dropped support for old GTK+ and GLib, requiring 2.10.0 and 2.12.0 respectively. Visibly, that means we can't support Windows 98 anymore, but I think we can say that's an acceptable loss by now. For development purposes, though, that means a ton of code that can be removed. It means a lot less code that needs to be maintained. We also were able to upgrade some things like from EggTrayIcon to GtkStatusIcon, which is better at integrating into the notification area.
Don't worry; it wasn't all development changes. We've also got integrated Mood setting. This interfaces to ICQ and XMPP, so I don't know too much about it. More in my area, MSN gained support for file transfer previews, which show up in the request window and the conversation.
There are quite a few other changes that I don't really even know about, so you might want to check the ChangeLog.
So last week the accepted proposals for GSoC were announced. Pidgin was given 4 slots.
First up, we have Ivan Komarov working on improving ICQ. I don't really use ICQ, so I can't say much, but if you do, hopefully there'll be a lot of great things coming out of it that will be useful to you. Next up is Adam Fowler working on a better chat log viewer. People really seem to complain about what we have now and at the very least, it's kind of slow once you have a lot of logs, so there should be room for some good improvements there. And then we have Gilles Bedel working on detachable libpurple sessions. I'm not sure how often I'd use it, but every once in a while, I feel like checking in on Pidgin from the laptop and it's a very painful process through SSH and D-Bus. This project should make that sort of thing much simpler. Finally, we have Jorge Villaseñor Salinas working on refactoring MSN.
So that last one is the one I'm mentoring. Personally, I've been wanting to re-write bits and pieces of the MSN prpl for a while now, but I've never had the time to get around to it. Jorge's already done some great work getting custom smiley support working for Pidgin 2.5.0. I'm sure he'll have no problem re-working the MSN prpl. I'm looking forward to getting a more structured and (hopefully) well-designed prpl which should make development a lot easier and quicker.
April 30, 2010 02:46 AM by John Bailey
OK, maybe I'm being a bit sensationalist there, but it's my blog, so I'm allowed! Anyway, on to the subject matter.
Recently we've seen a few users in #pidgin (and I've received some emails too) with some strange issues that result from plugins doing things they really
shouldn't but can anyway. I'm going to run down a small punch list of items for you, as plugin authors, to do to prevent your users having hard-to-diagnose issues.
Never use printf() in a plugin. This causes terminal disruption for Finch users and is a bad idea in general. It will probably behave unpredictably on Windows and/or in other UI's too. We provide a debugging API to avoid this kind of stuff. Instead of printf(), use purple_debug_info() or purple_debug_misc(). You can see the debug output (even during initial startup) if you run 'pidgin -d', even on Windows and even if your Pidgin is built without '--enable-debug'. For Finch, you can do 'finch -d 2> finch_debug.txt' to get your debug info. Don't lie about UI requirements. If you use GTK+, you're a Pidgin plugin, not a "core" (or libpurple) plugin. If you use GNT (or if you're really brave and use ncurses directly), you're a Finch plugin. There are plenty of examples in the Pidgin and Purple Plugin Pack source trees that show you how to properly declare your UI dependency. The UI requirement is designed specifically so that plugins requiring a specific UI can't be loaded by, and thus cause problems for, other UI's. Sure, it's possible to make a UI-agnostic plugin that requires GTK+, but I guarantee it will cause at least one or two Finch users unnecessary problems.
Install your binaries to the correct place. If you're installing a Pidgin plugin, install to $prefix/lib/pidgin, not $prefix/lib/purple-2. If you're installing a Finch plugin, install to $prefix/lib/finch. This will prevent other UI's from needlessly trying to probe your plugin and is just general courtesy. (Note that this particular item doesn't apply to plugins for Pidgin on Windows at the moment, but may be important later.) If your plugin is a protocol plugin, you absolutely are not allowed to touch UI-specific code at all. That means no GTK+, no GNT, no XUL, etc. If you need UI elements, use the request API libpurple provides. If the request API doesn't cut it, there are other approaches you can take, such as having two plugins, one of which does the actual protocol work and the other providing the UI. A better approach, though, is helping us identify where the request API is lacking so we can improve it. We know our API's aren't perfect, so when someone can show us a concrete reason why we're deficient, we will try to fix that deficiency.
Please check your plugins for these problems and help your users have a more pleasant experience with your plugins!
April 27, 2010 08:27 PM by John Bailey
It feels like it's been forever since I stepped up on the soapbox to say something. This time it's just a relatively short update.
As is very commonly known, Pidgin was accepted as a mentoring organization for the Google Summer of Code again this year. This year, Google has given us the privilege of mentoring four students. While less than we hoped for (we'd wanted five), we certainly can't complain about the projects we were able to accept.
First up is an MSN project manned by Jorge Villasenor Salinas, who some may recognize as having helped implement custom emoticon support for Pidgin 2.5.0. His project is to rewrite the SLP layer of the MSN plugin, simplify the other parts of the plugin, and overall make the plugin much easier to maintain and extend. I'm sure he'll be trying to squeeze some new features into his project if time allows.
Next up is one of my personal favorite projects for this year. Gilles Bedel will be working on detachable sessions. This is something a number of us have wanted for a long time, but just haven't quite gotten around to making it happen. The idea here is that we can have a daemon (service for the Windows-inclined among us) running in the background and connect to it with Pidgin or Finch at will. I feel that this is perhaps the most ambitious project this year, but the benefits it could reap are worth it.
Adam Fowler is going to rewrite the log viewer in Pidgin. This particular project will likely be the only project that visibly changes Pidgin this year. We've received a lot of complaints and suggestions over the years focusing on our log viewer. We know it's deficient in a lot of ways, and that's what Adam's project aims to resolve. I'm confident we'll get a lot of positive feedback about this project once it's complete.
And last, but not least, is Ivan Komarov's ICQ project. Ivan's aim is to beat our ICQ implementation into shape. As most of our non-US ICQ users can confirm, our interaction with the service could use some improvements. While Ivan has proposed a nice wide range of things to fix, even just a few of them being completed would make a huge difference for our international users.
So, from all of us developers, and we hope from our users too, good luck to our students!
April 02, 2010 07:31 AM by Mark Doliner
When I started working on Pidgin eight years ago (eight years‽ holy crap!) my main focus was the code used to connect to AIM and ICQ. The protocol is called ‘OSCAR,’ and it is a proprietary protocol created by AOL.
As IM protocols go, OSCAR is actually quite decent. Flexible, extensible, reasonably concise. Could maybe be simpler.
Background
AOL’s history with public access to their IM network has had its ups and downs.
In 1998 a few AOL employees released a GPLv2-licensed IM program called ‘TiK.’ Sometime in 1999 this project was abandoned by the AOL employees. Some non-AOL employees created a TiK project on SourceForge and continued development. Things were good. In 2001 AOL made changes to their protocol in an attempt to block unofficial clients. Some people believe these changes were made to block Jabber<–>AIM transports, and that Pidgin (named ‘Gaim’ at the time) got caught in the crossfire. Pidgin developers were able to keep the program working for the most part, and AOL relaxed their efforts to block unofficial clients. Things were good again. In 2008 AOL announced Open AIM. Open AIM was a lot of things: A set of SDKs for interfacing with AIM and the AIM servers. Documentation for the OSCAR protocol. A forum for users to ask questions. Things were great… for a time.
Recent Changes
Sometime in January, February or March of this year AOL decided to shut down the Open AIM program. No more SDKs, no more protocol documentation, and no more developer outreach.
More specifically, the OSCAR documentation provided by AOL described a method of authentication (using a “startOSCARSession” API request) that required the use of a developer application key. The current Open AIM website implies that new keys cannot be created.
Now What?
Does this mean the use of startOSCARSession is deprecated? If so, what auth scheme should we use, instead? Should we go back to BUCP, the authentication scheme used by AIM 5.9? Should we try to reverse engineer the authentication scheme used by current version of AIM? Should we go back to masquerading as the official AIM client and stop politely identifying ourselves as ‘Pidgin’?
To quote the great Yoda, “the shroud of the dark side has fallen.”
Last updated: February 16, 2012 02:00 PM (All times are UTC.)
Powered by: 
![[image]](http://mowser.com/img?url=http%3A%2F%2Fplanet.pidgin.im%2Fshared%2Fimg%2Ffeed.png)
