On November 13, I mailed our development list about our open patches. At the time we had 93 patches open on our Trac. Since then, some work has gone on with respect to patches, a lot of it from me. In the last 17 days, there have been 23 patches committed. Not all of those tickets were marked as patches, however. There have also been a number of new patch tickets opened, bringing our total patch count down by only 11 to 82.
Now, out of those 82 patches, if we ignore the ones we've put on the Patches Needing Improvement milestone, we have 57 patches. Here is where we see a significant difference, as out of the former 93 patches, 75 were not on a milestone, indicating that the patches that have changed to the Patches Needing Improvement milestone had not been previously reviewed, or had been reviewed but not marked appropriately on Trac.
Among some notable patches that were accepted include MD5 authentication support for ICQ; fixes for Gadu-Gadu, Zephyr, and SIMPLE; ICQ X-status support (which can't be included until at least 2.6.0); and support for connecting to an XMPP server without specifying a resource, thus causing compliant servers to generate a resource for us. Aside from the X-status patch, all the ones I've just mentioned will be in 2.5.3.
But the work isn't done yet! We still need a lot of patch review from Pidgin developers. Also, a lot of patches need work, so there's still plenty to do if anyone wants to help! I, for one, certainly won't complain if someone comes along and fixes up a patch that needs work, and such fixing will make it much more likely that the patch will be accepted.
For reference, I also mailed the development list earlier today to discuss patches again, here.
Ah, how our work never ends...
Sunday, November 30, 2008
Tuesday, October 7, 2008
The Hosting Game
Well, by now probably everyone's aware that our (Pidgin's) sites had been down for several days. Here's the basic rundown of what's happened with our servers over the last couple years.
Prior to our going public with our rename, Luke Schierer secured a donation of a virtual server from DVLabs. This server was intended to enable us to migrate away from SourceForge's web platform and tracker. It allowed us to have our own domains, and thus host and control our own e-mail services, mailing lists, and Trac. This server did its job for us quite well, even though we did occasionally push the server to or beyond its limits. (Note that in these instances real hardware would actually not have made a noticable difference at all, as all the resources of the real hardware would have been utilized just as we had experienced in the virtual machine.)
Even though we were extremely grateful to DVLabs for providing us a server, we did realize that having only a single server presented us with some limitations, the most important of which is "graceful" failure of core services if the server goes down. It also presented a single point of failure in that the web server getting pounded (such as a posting to Slashdot causes) could potentially cause all our services, including monotone and mail, to grind to a halt. Because of this we had tossed around the idea of finding another host two or three times.
When we most recently thought about hosting, Evan Schoenberg from the Adium project (who also happens to be a libpurple developer) put us in contact with NetworkRedux, who generously provides Adium's hosting. Thanks to Evan's intervention, we spoke with NetworkRedux about our hosting, and they were willing to donate not just one, but two servers and a ton of bandwidth to our project. Thanks to NetworkRedux's generous offer, we're getting the potential to have a lot more raw computing power at our disposal (including more memory to help increase caches, thus hopefully improving speed), as well as the ability to spread our services out a little so that a heavy hit to the website or to trac won't have a detrimental effect on all our services.
We were still discussing details of migrating to these two new servers when the server at DVLabs unexpectedly went down. It turns out that some miscommunication and bad timing caused the guys at DVLabs, who were migrating their own stuff, to down the server hosting our virtual machine, thinking we were no longer using it. We were, of course, confused at first, but once we determined what was happening we were much more at ease. None of our data had been lost. DVLabs were kind enough to supply us with the raw VM image for our own use to recover our data and complete our migration.
From these events we have learned a lesson--redundancy is not only good, it's pretty much a must-have. In the interests of redundancy and graceful failover, we've taken some steps to help prevent future long-term outages. One of those steps is that Gary Kramlich and I decided that we would help out by providing some service redundancy on our server, guifications.org. The biggest, and most important, service we are helping with is monotone. If for some reason the monotone server is down, guifications.org can seamlessly stand in for the mtn.pidgin.im server through the magic of DNS. We're also looking at potentially acting as a backup for more services.
So all in all, the commotion about our sites being down was really just a lot of noise about nothing truly significant. Yes, our sites were down, but this wasn't the end of the world. Google's massive cache had pretty much all the critical information anyone could need from our wiki. Yes, monotone was down, but guifications.org was ready to help--I had been running a read-only mirror for nearly a year which was ready and able to stand in as a production service if needed. Our mailing lists were down as well, but again, it wasn't the end of the world. Overall, we have weathered a prolonged service outage pretty well and taken some lessons from it to help us in the future.
In closing, I would like to extend my deepest, most heartfelt thanks on behalf of all Pidgin developers to DVLabs for their hosting services over the past two years and to NetworkRedux for the services they are now providing for us. We truly appreciate these donations!
Prior to our going public with our rename, Luke Schierer secured a donation of a virtual server from DVLabs. This server was intended to enable us to migrate away from SourceForge's web platform and tracker. It allowed us to have our own domains, and thus host and control our own e-mail services, mailing lists, and Trac. This server did its job for us quite well, even though we did occasionally push the server to or beyond its limits. (Note that in these instances real hardware would actually not have made a noticable difference at all, as all the resources of the real hardware would have been utilized just as we had experienced in the virtual machine.)
Even though we were extremely grateful to DVLabs for providing us a server, we did realize that having only a single server presented us with some limitations, the most important of which is "graceful" failure of core services if the server goes down. It also presented a single point of failure in that the web server getting pounded (such as a posting to Slashdot causes) could potentially cause all our services, including monotone and mail, to grind to a halt. Because of this we had tossed around the idea of finding another host two or three times.
When we most recently thought about hosting, Evan Schoenberg from the Adium project (who also happens to be a libpurple developer) put us in contact with NetworkRedux, who generously provides Adium's hosting. Thanks to Evan's intervention, we spoke with NetworkRedux about our hosting, and they were willing to donate not just one, but two servers and a ton of bandwidth to our project. Thanks to NetworkRedux's generous offer, we're getting the potential to have a lot more raw computing power at our disposal (including more memory to help increase caches, thus hopefully improving speed), as well as the ability to spread our services out a little so that a heavy hit to the website or to trac won't have a detrimental effect on all our services.
We were still discussing details of migrating to these two new servers when the server at DVLabs unexpectedly went down. It turns out that some miscommunication and bad timing caused the guys at DVLabs, who were migrating their own stuff, to down the server hosting our virtual machine, thinking we were no longer using it. We were, of course, confused at first, but once we determined what was happening we were much more at ease. None of our data had been lost. DVLabs were kind enough to supply us with the raw VM image for our own use to recover our data and complete our migration.
From these events we have learned a lesson--redundancy is not only good, it's pretty much a must-have. In the interests of redundancy and graceful failover, we've taken some steps to help prevent future long-term outages. One of those steps is that Gary Kramlich and I decided that we would help out by providing some service redundancy on our server, guifications.org. The biggest, and most important, service we are helping with is monotone. If for some reason the monotone server is down, guifications.org can seamlessly stand in for the mtn.pidgin.im server through the magic of DNS. We're also looking at potentially acting as a backup for more services.
So all in all, the commotion about our sites being down was really just a lot of noise about nothing truly significant. Yes, our sites were down, but this wasn't the end of the world. Google's massive cache had pretty much all the critical information anyone could need from our wiki. Yes, monotone was down, but guifications.org was ready to help--I had been running a read-only mirror for nearly a year which was ready and able to stand in as a production service if needed. Our mailing lists were down as well, but again, it wasn't the end of the world. Overall, we have weathered a prolonged service outage pretty well and taken some lessons from it to help us in the future.
In closing, I would like to extend my deepest, most heartfelt thanks on behalf of all Pidgin developers to DVLabs for their hosting services over the past two years and to NetworkRedux for the services they are now providing for us. We truly appreciate these donations!
Sunday, August 24, 2008
It's a bit late...
It's a bit late for me to be posting this now, but we did recently release Pidgin 2.5.0. There are a few things about this release that I'd like to discuss:
MSNP15. Finally, we have a release which includes updated MSN protocol support. We now support the personal message, current media, and offline message features of recent MSN official clients. We do not, however, support fast file transfers. We still support only the MSN-server-proxied transfer method, which while slow is 100% reliable. Quite frankly, file transfer isn't a high priority. If someone wants to implement fast file transfers, feel free to submit patches to us.
Custom smileys. During the development cycle of 2.5.0, a patch was accepted that implemented custom smiley support on MSN and provided a framework within libpurple for other protocols supporting the feature to grow support. There is one issue with this support--we can't save an incoming animated GIF emoticon. This is a limitation in gdkpixbuf, which doesn't support saving the GIF format by default. There are perhaps some additional dependencies we could incur for this, but nothing has been done in this area yet. To set up your custom smileys, go to the "Tools" menu on the Buddy List window and select "Smiley."
AIM Tooltip Crash. We've had a number of duplicated reports of crashes when "mousing over" an AIM buddy. The crash happens when trying to display the tooltip, and only appears when Glib uses its internal vsnprintf() implementation (which happens on some non-glibc systems, such as Windows and the BSD flavors of UNIX). An updated liboscar.dll that fixes this problem is available on ticket #6627. Please don't open any more tickets about this bug!
There is one other AIM bug I'd like to mention, since we're aware it exists. Not too long ago it came to our attention that when a Pidgin user joins an AIM chatroom and tries to send messages, less than 25% of the messages actually make it to the other members of the room. We are aware of the bug, but I believe we're not yet fully certain of the cause. A bug report already exists (#6590), so please don't open any more tickets about this bug either!
Hopefully all you MSN users out there enjoy the new features. It's taken a long time to get the features out there, but I think in the end the wait is worth it.
- MSNP15 support
- Custom smiley support
- The Windows and *BSD AIM tooltip crash
MSNP15. Finally, we have a release which includes updated MSN protocol support. We now support the personal message, current media, and offline message features of recent MSN official clients. We do not, however, support fast file transfers. We still support only the MSN-server-proxied transfer method, which while slow is 100% reliable. Quite frankly, file transfer isn't a high priority. If someone wants to implement fast file transfers, feel free to submit patches to us.
Custom smileys. During the development cycle of 2.5.0, a patch was accepted that implemented custom smiley support on MSN and provided a framework within libpurple for other protocols supporting the feature to grow support. There is one issue with this support--we can't save an incoming animated GIF emoticon. This is a limitation in gdkpixbuf, which doesn't support saving the GIF format by default. There are perhaps some additional dependencies we could incur for this, but nothing has been done in this area yet. To set up your custom smileys, go to the "Tools" menu on the Buddy List window and select "Smiley."
AIM Tooltip Crash. We've had a number of duplicated reports of crashes when "mousing over" an AIM buddy. The crash happens when trying to display the tooltip, and only appears when Glib uses its internal vsnprintf() implementation (which happens on some non-glibc systems, such as Windows and the BSD flavors of UNIX). An updated liboscar.dll that fixes this problem is available on ticket #6627. Please don't open any more tickets about this bug!
There is one other AIM bug I'd like to mention, since we're aware it exists. Not too long ago it came to our attention that when a Pidgin user joins an AIM chatroom and tries to send messages, less than 25% of the messages actually make it to the other members of the room. We are aware of the bug, but I believe we're not yet fully certain of the cause. A bug report already exists (#6590), so please don't open any more tickets about this bug either!
Hopefully all you MSN users out there enjoy the new features. It's taken a long time to get the features out there, but I think in the end the wait is worth it.
Thursday, July 31, 2008
The Holy War of Tool Choice
Tools are vital to any open-source project. Because of that, tool choice is critical. You really don't want to be switching tools frequently, because doing so is more work than you'll ever be able to put into the project. By that same token, you don't want to pick tools no one in the project wants to use. This leads to the problem--tool choice is often a "Holy War", so to speak, because everyone has their pet tool and thinks everything else to be inferior.
Let's use Pidgin as a practical example. Prior to our most recent legal problems (which prompted our rename), we had been evaluating new version control software for some time. At that time, we were using CVS. Almost everyone who has developed on a project as large as Pidgin will agree that CVS sucks. You can't rename files unless you rename them in the repository itself, branching and merging are a pain, etc. I wasn't involved with the project at this point in time, but I do know that every distributed VCS in existence at the time was evaluated. After the evaluation, Monotone was the preferred choice. Keep in mind that this was over two years ago, more likely closer to three.
We continued to use CVS, and later made an ill-advised switch to Subversion. Sticking with these tools was mainly due to our complete reliance on SourceForge, who offered only CVS and SVN. Finally, when it came time to rename our project to Pidgin, we had a donated virtual server on which we could run (essentially) whatever we wanted. Ethan Blanton used tailor to convert our SVN repository into a monotone database.
We also set up Trac for bug, patch, and feature request tracking. The built-in wiki was a bonus. We ended up installing a number of plugins for Trac to customize it and provide some additional features, such as restricting some ticket fields from those who we feel should not be able to modify them.
All was well initially. We had a few complaints because we chose to use monotone instead of sticking with SVN, but these were users who had no intention of contributing patches, so we were (mostly) happy to see them angrily go back to using our "blessed" releases. We did, however, have a lot of confusion initially about what monotone was and how it related to Pidgin. A few hundred explanations later and those questions faded too.
Trac proved to have some scalability and performance issues for us on numerous occasions. Eventually we were able to narrow the biggest issues down to their causes and implement fixes. Some of this involved a LOT of poking and prodding, as well as some assistance from Trac developers, who we thank profusely for their time in resolving the issues. I am quite surprised, overall, that we haven't had any real complaints about Trac. For a while it was frequently completely unusable, and of course we saw a number of complaints related to that, but since the issues have been resolved we've seen no real complaints.
As for monotone, fast-forward a year from the announcement of the rename. We consistently get complaints about having to download a "huge" database just to get the latest development source for Pidgin. We do also get a few complaints that it's hard to use, but almost all of these are solved simply by pointing people at the UsingPidginMonotone wiki page. As for the huge database, we do acknowledge that it is inconvenient for some people, but "shallow-pull" support is coming to monotone. A shallow pull would be similar to an svn checkout.
I don't mind the database, myself. I have 11 working copies (checkouts) from my single pidgin database (8 distinct branches, plus duplicates of the last three branches I worked on or tested with). Each clean checkout (that is, a checkout prior to running autogen.sh and building) is approximately 61 MB. If this were SVN, each working copy would be approximately 122 MB due to svn keeping a pristine copy of every file to facilitate 'svn diff' and 'svn revert' without needing to contact the server the working copy was pulled from. Now, let's add that up. For SVN, I would have 11 times 122 MB, or 1342 MB, just in working copies. For monotone, I have 11 times 61 MB for the working copies (671 MB), plus 229 MB for the database, for a grand total of 900 MB. For me, this is an excellent bargain, as I save 442 MB of disk space thanks to the monotone model. For another compelling comparison that's sure to ruffle a few feathers, let's compare to git. If I clone the git mirror of our monotone repository, I find a checkout size of 148 MB after git-repack--running git-gc also increased the size by 2 MB, but I'll stick with the initial checkout size for fairness. If I multiply this by my 11 checkouts, I will have 1628 MB. This is even more compelling for me, as I now save 728 MB of disk space with monotone.
Richard Laager also took the time to point out an interesting, but as yet unexploited feature of monotone--the use of certs allow us to do a number of useful things while being backed by the cryptographic signing of certs. For one, we could implement something similar to the kernel's Signed-Off-By markers. We could also have an automated test suite run compiles of each revision and add a cert indicating whether or not the test succeeded. We could also include a test suite using check (we do already have some tests) and use more certs to indicate success or failure. The extensibility of monotone using lua and the certificates is truly mind-boggling.
I think I've picked on version control enough here, but before I move on, I'd like to say that I don't specifically hate any one version control system. Ok, maybe I hate CVS and Subversion, but I'm certainly not alone in that. I don't, however, hate git, bzr, hg, etc. In fact, I think hg looks quite promising--the Adium folks have decided to switch to it, and are currently in the process of trying to convert from SVN. However, given that for us monotone was the best choice when we made our decision, and given the extensibility of monotone, I think it would be foolish of us to choose another tool at this point. Perhaps in a few more years when all the DVCSes have had time to mature further it will make sense to revisit this decision.
Another tool choice involves communication between developers and users. Specifically, forums. We have elected not to have forums for Pidgin, although as a legacy of our continued involvement with Sourceforge for download hosting we are stuck with the forums they provided us. We are quite frequently belittled for our choice to forego widely visible forums. At least four of us that I am aware of have a strong distaste for forums. I find them to be worse than the ticket system for attracting duplicated questions which most users won't search beforehand. All the useless extra features, such as emoticons, formatting, etc., are a waste, as well.
It's also been my experience with forums that one or two people will start answering others' questions with misinformation that will sound legitimate to those receiving the bad answers. I've seen this numerous times, but it comes to mind so quickly as I've seen it quite recently on Ubuntu's Launchpad "Questions" forum or tracker or whatever you call it for Pidgin.
Instead of forums, we have chosen to use mailing lists. We receive complaints about this too. These complaints run the gamut from "mailing lists are hard to use" to "but you can't search the mailing list!" In reality, the mailing lists are searchable--Google indexes our mailing lists, as do a number of other search engines. Perhaps we could provide a nice search box or something that does the necessary google magic (make the search query "terms site:pidgin.im") to make it a bit friendlier, but searchability exists. Not that it matters much in my experience, but hey, I'm just a developer; what do I know?
I'd also argue that mailing lists are easier to use than forums, as all you have to do is, y'know, send an e-mail. With a forum, you have to register, log in, find the right forum if there is more than one, then post your question, and check back for answers. With the mailing list, those genuinely interested in providing assistance will helpfully use the "Reply All" feature of their mail client to provide the answer both to the user requesting help and the mailing list's archive, thus providing an answer that is both helpful and searchable.
Even so, all the choices made during the evolution of a project will result in people trying to start a crusade, holy war, revolt, ..., over the chosen tool. Unfortunately, it's a fact of life. The best we can do is take it in stride, justify our choices, and move on.
Note: It's come to my attention that I had missed the ability to share a git database across multiple working copies. In that scenario, the total size of the database and 11 working copies is slightly under 750 MB, and thus a space savings in the neighborhood of 150 MB over monotone. It had been my understanding that I needed a copy of the database per working copy. I stand corrected. I don't use git on a daily basis, as the projects I work with currently use CVS, SVN, or monotone, so I am bound to miss finer details of git here and there. There are other reasons I prefer to stick with monotone, but I won't get into them here, as they're not important to the point of this post.
Let's use Pidgin as a practical example. Prior to our most recent legal problems (which prompted our rename), we had been evaluating new version control software for some time. At that time, we were using CVS. Almost everyone who has developed on a project as large as Pidgin will agree that CVS sucks. You can't rename files unless you rename them in the repository itself, branching and merging are a pain, etc. I wasn't involved with the project at this point in time, but I do know that every distributed VCS in existence at the time was evaluated. After the evaluation, Monotone was the preferred choice. Keep in mind that this was over two years ago, more likely closer to three.
We continued to use CVS, and later made an ill-advised switch to Subversion. Sticking with these tools was mainly due to our complete reliance on SourceForge, who offered only CVS and SVN. Finally, when it came time to rename our project to Pidgin, we had a donated virtual server on which we could run (essentially) whatever we wanted. Ethan Blanton used tailor to convert our SVN repository into a monotone database.
We also set up Trac for bug, patch, and feature request tracking. The built-in wiki was a bonus. We ended up installing a number of plugins for Trac to customize it and provide some additional features, such as restricting some ticket fields from those who we feel should not be able to modify them.
All was well initially. We had a few complaints because we chose to use monotone instead of sticking with SVN, but these were users who had no intention of contributing patches, so we were (mostly) happy to see them angrily go back to using our "blessed" releases. We did, however, have a lot of confusion initially about what monotone was and how it related to Pidgin. A few hundred explanations later and those questions faded too.
Trac proved to have some scalability and performance issues for us on numerous occasions. Eventually we were able to narrow the biggest issues down to their causes and implement fixes. Some of this involved a LOT of poking and prodding, as well as some assistance from Trac developers, who we thank profusely for their time in resolving the issues. I am quite surprised, overall, that we haven't had any real complaints about Trac. For a while it was frequently completely unusable, and of course we saw a number of complaints related to that, but since the issues have been resolved we've seen no real complaints.
As for monotone, fast-forward a year from the announcement of the rename. We consistently get complaints about having to download a "huge" database just to get the latest development source for Pidgin. We do also get a few complaints that it's hard to use, but almost all of these are solved simply by pointing people at the UsingPidginMonotone wiki page. As for the huge database, we do acknowledge that it is inconvenient for some people, but "shallow-pull" support is coming to monotone. A shallow pull would be similar to an svn checkout.
I don't mind the database, myself. I have 11 working copies (checkouts) from my single pidgin database (8 distinct branches, plus duplicates of the last three branches I worked on or tested with). Each clean checkout (that is, a checkout prior to running autogen.sh and building) is approximately 61 MB. If this were SVN, each working copy would be approximately 122 MB due to svn keeping a pristine copy of every file to facilitate 'svn diff' and 'svn revert' without needing to contact the server the working copy was pulled from. Now, let's add that up. For SVN, I would have 11 times 122 MB, or 1342 MB, just in working copies. For monotone, I have 11 times 61 MB for the working copies (671 MB), plus 229 MB for the database, for a grand total of 900 MB. For me, this is an excellent bargain, as I save 442 MB of disk space thanks to the monotone model. For another compelling comparison that's sure to ruffle a few feathers, let's compare to git. If I clone the git mirror of our monotone repository, I find a checkout size of 148 MB after git-repack--running git-gc also increased the size by 2 MB, but I'll stick with the initial checkout size for fairness. If I multiply this by my 11 checkouts, I will have 1628 MB. This is even more compelling for me, as I now save 728 MB of disk space with monotone.
Richard Laager also took the time to point out an interesting, but as yet unexploited feature of monotone--the use of certs allow us to do a number of useful things while being backed by the cryptographic signing of certs. For one, we could implement something similar to the kernel's Signed-Off-By markers. We could also have an automated test suite run compiles of each revision and add a cert indicating whether or not the test succeeded. We could also include a test suite using check (we do already have some tests) and use more certs to indicate success or failure. The extensibility of monotone using lua and the certificates is truly mind-boggling.
I think I've picked on version control enough here, but before I move on, I'd like to say that I don't specifically hate any one version control system. Ok, maybe I hate CVS and Subversion, but I'm certainly not alone in that. I don't, however, hate git, bzr, hg, etc. In fact, I think hg looks quite promising--the Adium folks have decided to switch to it, and are currently in the process of trying to convert from SVN. However, given that for us monotone was the best choice when we made our decision, and given the extensibility of monotone, I think it would be foolish of us to choose another tool at this point. Perhaps in a few more years when all the DVCSes have had time to mature further it will make sense to revisit this decision.
Another tool choice involves communication between developers and users. Specifically, forums. We have elected not to have forums for Pidgin, although as a legacy of our continued involvement with Sourceforge for download hosting we are stuck with the forums they provided us. We are quite frequently belittled for our choice to forego widely visible forums. At least four of us that I am aware of have a strong distaste for forums. I find them to be worse than the ticket system for attracting duplicated questions which most users won't search beforehand. All the useless extra features, such as emoticons, formatting, etc., are a waste, as well.
It's also been my experience with forums that one or two people will start answering others' questions with misinformation that will sound legitimate to those receiving the bad answers. I've seen this numerous times, but it comes to mind so quickly as I've seen it quite recently on Ubuntu's Launchpad "Questions" forum or tracker or whatever you call it for Pidgin.
Instead of forums, we have chosen to use mailing lists. We receive complaints about this too. These complaints run the gamut from "mailing lists are hard to use" to "but you can't search the mailing list!" In reality, the mailing lists are searchable--Google indexes our mailing lists, as do a number of other search engines. Perhaps we could provide a nice search box or something that does the necessary google magic (make the search query "terms site:pidgin.im") to make it a bit friendlier, but searchability exists. Not that it matters much in my experience, but hey, I'm just a developer; what do I know?
I'd also argue that mailing lists are easier to use than forums, as all you have to do is, y'know, send an e-mail. With a forum, you have to register, log in, find the right forum if there is more than one, then post your question, and check back for answers. With the mailing list, those genuinely interested in providing assistance will helpfully use the "Reply All" feature of their mail client to provide the answer both to the user requesting help and the mailing list's archive, thus providing an answer that is both helpful and searchable.
Even so, all the choices made during the evolution of a project will result in people trying to start a crusade, holy war, revolt, ..., over the chosen tool. Unfortunately, it's a fact of life. The best we can do is take it in stride, justify our choices, and move on.
Note: It's come to my attention that I had missed the ability to share a git database across multiple working copies. In that scenario, the total size of the database and 11 working copies is slightly under 750 MB, and thus a space savings in the neighborhood of 150 MB over monotone. It had been my understanding that I needed a copy of the database per working copy. I stand corrected. I don't use git on a daily basis, as the projects I work with currently use CVS, SVN, or monotone, so I am bound to miss finer details of git here and there. There are other reasons I prefer to stick with monotone, but I won't get into them here, as they're not important to the point of this post.
Sunday, July 13, 2008
"State of the MSN Plugin Address"
Yes, the title is intended to be half joking. Just a few days ago I made a comment to a fellow developer that "someone needs to make a 'state of the msn plugin' address," meaning that someone needs to let people know what's happening. Well, looks like that someone's going to be me. So here's the outsider's summary of what's happened.
In current Pidgin releases, the default MSN plugin uses the old MSNP9 protocol. This protocol doesn't support Personal Status Messages (PSM, also called "personal messages"), nor does it support offline IM, current media (a field that shows what music you're listening to or what video you're watching), or messaging while invisible.
Two years ago, for the 2006 Summer of Code, we had a student whose project was to update our MSN code to MSNP13. MSNP13 supported the PSM and current media, although at the time libpurple didn't support the status attributes for "now playing" or "current media" or whatever you prefer to call it. MSNP13 may also have supported messaging while offline, but I can't recall for certain and I don't, at the moment, feel like looking it up in the documentation we have online. Later this was updated to MSNP14 for Yahoo! interoperability support. At the end of the summer, the code wasn't of a quality we were ready to release. The code sat.
Last year, we had another student take on MSN protocol updating. This time the student updated the code to support MSNP14, starting from the previous work. This supported offline messaging for sure, and there were a lot of commits that dealt with the OIM features. Again, at the end of the summer, the code wasn't release-ready in our opinion, so again the code sat.
Earlier this year, one of our developers started working on the MSNP14 code in a side branch, and eventually merged it to the im.pidgin.pidgin branch in our monotone repository. Because the code still wasn't release-ready, we disabled it and forced the MSNP9 plugin to build by default. The more clever users were still able to figure out how to get MSNP14 going, but there weren't too many until we introduced an argument to the configure script to enable the MSNP14 plugin.
A new "crazy patch writer" appeared and started to work on MSNP15 support. We eventually gave him write access to the central monotone repository at pidgin.im. This has paid off for us very well. Elliott has done a LOT of work, including some necessary cleanup, stability improvements, etc. MSNP15 was finally merged to im.pidgin.pidgin this morning. Currently it is also the default MSN plugin, and I hope it stays that way, but it might be changed if anyone objects to it.
This would not have been possible without the work of Elliott, the two Summer of Code students, one other crazy patch writer (known as Masca on #pidgin), our XMPP Voice and Video Summer of Code student for this year (known as Maiku on #pidgin), and Dimmuxx and other Adium users' testing. I'm sure there are a number of other people I've forgotten to mention who have made contributions to this progress, and I apologize. My memory isn't what it used to be. To all these people who have helped with the long road of updated MSN protocol support, I give well-deserved thanks.
So what does all this mean? Well, simply, a lot of the feature requests we've been getting are finally resolved. Ideally we also will stop seeing people asking why they don't receive offline MSN messages, why they can't message while invisible, and why they can't see personal messages. For these reasons alone, I can't wait for the release of Pidgin 2.5.0!
In current Pidgin releases, the default MSN plugin uses the old MSNP9 protocol. This protocol doesn't support Personal Status Messages (PSM, also called "personal messages"), nor does it support offline IM, current media (a field that shows what music you're listening to or what video you're watching), or messaging while invisible.
Two years ago, for the 2006 Summer of Code, we had a student whose project was to update our MSN code to MSNP13. MSNP13 supported the PSM and current media, although at the time libpurple didn't support the status attributes for "now playing" or "current media" or whatever you prefer to call it. MSNP13 may also have supported messaging while offline, but I can't recall for certain and I don't, at the moment, feel like looking it up in the documentation we have online. Later this was updated to MSNP14 for Yahoo! interoperability support. At the end of the summer, the code wasn't of a quality we were ready to release. The code sat.
Last year, we had another student take on MSN protocol updating. This time the student updated the code to support MSNP14, starting from the previous work. This supported offline messaging for sure, and there were a lot of commits that dealt with the OIM features. Again, at the end of the summer, the code wasn't release-ready in our opinion, so again the code sat.
Earlier this year, one of our developers started working on the MSNP14 code in a side branch, and eventually merged it to the im.pidgin.pidgin branch in our monotone repository. Because the code still wasn't release-ready, we disabled it and forced the MSNP9 plugin to build by default. The more clever users were still able to figure out how to get MSNP14 going, but there weren't too many until we introduced an argument to the configure script to enable the MSNP14 plugin.
A new "crazy patch writer" appeared and started to work on MSNP15 support. We eventually gave him write access to the central monotone repository at pidgin.im. This has paid off for us very well. Elliott has done a LOT of work, including some necessary cleanup, stability improvements, etc. MSNP15 was finally merged to im.pidgin.pidgin this morning. Currently it is also the default MSN plugin, and I hope it stays that way, but it might be changed if anyone objects to it.
This would not have been possible without the work of Elliott, the two Summer of Code students, one other crazy patch writer (known as Masca on #pidgin), our XMPP Voice and Video Summer of Code student for this year (known as Maiku on #pidgin), and Dimmuxx and other Adium users' testing. I'm sure there are a number of other people I've forgotten to mention who have made contributions to this progress, and I apologize. My memory isn't what it used to be. To all these people who have helped with the long road of updated MSN protocol support, I give well-deserved thanks.
So what does all this mean? Well, simply, a lot of the feature requests we've been getting are finally resolved. Ideally we also will stop seeing people asking why they don't receive offline MSN messages, why they can't message while invisible, and why they can't see personal messages. For these reasons alone, I can't wait for the release of Pidgin 2.5.0!
Friday, July 4, 2008
Pidgin 2.4.3 and ICQ
Well, this week has certainly been interesting with Pidgin development. On July 1, AOL made a small change to the OSCAR servers that affected our ICQ users. A lot of misinformation was spread in #pidgin about what really happened, so here's my best attempt to explain it.
Libpurple (and thus Pidgin and Finch) identified itself as ICQ basic 14.34.3000. Of course, we sent a version string that included our real identification ("Purple/2.4.2" for example). This has worked for us for years. We send the version bytes from official clients to the server because if we don't mimic an official client, we get locked out of some features. Which features, I'm not really sure, since I don't really know or care about the internals of the OSCAR protocol.
Suddenly we started seeing reports about ICQ no longer working in #pidgin. Upon investigation we discovered that apparently the client ID has been "retired", and any logins from that client ID are immediately met with a message from the server demanding an upgrade to ICQ6. The server then forcibly disconnects us. We catch this error and display a somewhat different message instructing our users to go to pidgin.im to get an update.
Stu Tomlinson found the version identification information for the most current official ICQ client and changed our identification. Magically logging in and holding a conversation works. This patch became the reason for the release of Pidgin 2.4.3.
So to summarize, this was NOT a protocol change, merely a tweak on the server side to disallow logins from "old" clients. I suspect this is to try to weed out older, buggier clients and get the users on current software.
Libpurple (and thus Pidgin and Finch) identified itself as ICQ basic 14.34.3000. Of course, we sent a version string that included our real identification ("Purple/2.4.2" for example). This has worked for us for years. We send the version bytes from official clients to the server because if we don't mimic an official client, we get locked out of some features. Which features, I'm not really sure, since I don't really know or care about the internals of the OSCAR protocol.
Suddenly we started seeing reports about ICQ no longer working in #pidgin. Upon investigation we discovered that apparently the client ID has been "retired", and any logins from that client ID are immediately met with a message from the server demanding an upgrade to ICQ6. The server then forcibly disconnects us. We catch this error and display a somewhat different message instructing our users to go to pidgin.im to get an update.
Stu Tomlinson found the version identification information for the most current official ICQ client and changed our identification. Magically logging in and holding a conversation works. This patch became the reason for the release of Pidgin 2.4.3.
So to summarize, this was NOT a protocol change, merely a tweak on the server side to disallow logins from "old" clients. I suspect this is to try to weed out older, buggier clients and get the users on current software.
Monday, April 21, 2008
Google Summer of Code, Pidgin, and Announcing Vulture
Well, as probably everyone reading this blog knows, yesterday was the day that accepted students were announced for the Google Summer of Code. I think I can safely say that for the most part we Pidgin developers are happy with the results. That said, I do wish we could have accepted two students who did not make the final six.
One of those two students applied for the native Windows user interface project. The student in question was actually our top-ranked Windows UI application, and was going to be accepted until we yielded to another organization when a conflict arose. He has been very good about all this and wants to work on his Windows UI project anyway, once the Summer of Code is complete. To that end, I have set up a project called Vulture (in keeping with the bird theme for libpurple UI's--Pidgin, Finch, Adium, Instantbird). I've also created a basic svn repository for the project, done because Trac integration with monotone really sucks at present. If it turns out that monotone would actually be more useful, we can always use tailor to convert later.
Since the student will be participating in another organization's Summer of Code, at the moment I'm basically flying solo, but I do welcome any help others can provide, as I'm not a Windows developer. I can dabble in a bit here and there, but I'm far from well-enough versed to be an effective developer on this project. I will do what I can, but it's always been my intention to be involved in a support capacity and also to help shape the progress of the application (in so much as the active developers are willing to put up with me and consider my opinions). I would, of course, also act as a representative within the Pidgin project to help ensure that any needs Vulture may have of libpurple are met as best they can be.
It's my hope that the buzz Summer of Code created around the native Windows user interface project remains and attracts people to actually work with us to produce a .NET libpurple client that can really fit the needs of Windows users better than Pidgin can. It's also my hope that it can be done while remaining as similar to Pidgin as possible. I think that these two hopes are completely compatible and doable--Pidgin represents a pretty reasonable UI as it stands. There are, of course, a few points of pretty hot contention, but we can deal with that in Vulture by developer consensus at first, and let user input shape the decisions beyond that if we want.
So, happy Summer of Code to our accepted students, and for anyone who cares to join us at Vulture, feel free to drop us a line! :)
One of those two students applied for the native Windows user interface project. The student in question was actually our top-ranked Windows UI application, and was going to be accepted until we yielded to another organization when a conflict arose. He has been very good about all this and wants to work on his Windows UI project anyway, once the Summer of Code is complete. To that end, I have set up a project called Vulture (in keeping with the bird theme for libpurple UI's--Pidgin, Finch, Adium, Instantbird). I've also created a basic svn repository for the project, done because Trac integration with monotone really sucks at present. If it turns out that monotone would actually be more useful, we can always use tailor to convert later.
Since the student will be participating in another organization's Summer of Code, at the moment I'm basically flying solo, but I do welcome any help others can provide, as I'm not a Windows developer. I can dabble in a bit here and there, but I'm far from well-enough versed to be an effective developer on this project. I will do what I can, but it's always been my intention to be involved in a support capacity and also to help shape the progress of the application (in so much as the active developers are willing to put up with me and consider my opinions). I would, of course, also act as a representative within the Pidgin project to help ensure that any needs Vulture may have of libpurple are met as best they can be.
It's my hope that the buzz Summer of Code created around the native Windows user interface project remains and attracts people to actually work with us to produce a .NET libpurple client that can really fit the needs of Windows users better than Pidgin can. It's also my hope that it can be done while remaining as similar to Pidgin as possible. I think that these two hopes are completely compatible and doable--Pidgin represents a pretty reasonable UI as it stands. There are, of course, a few points of pretty hot contention, but we can deal with that in Vulture by developer consensus at first, and let user input shape the decisions beyond that if we want.
So, happy Summer of Code to our accepted students, and for anyone who cares to join us at Vulture, feel free to drop us a line! :)
Subscribe to:
Posts (Atom)