People often ask what's taking so long with Pidgin 3's development. Some have even suggested that we should just release what we have. This is the topic we're going to cover in this post.
To help explain this we have to go back in history to 1998. That is when Mark Spencer started writting a little program named Gaim to learn how to create graphical applications on Linux.
Gaim was created as an AOL Instant Messgener client but grew support for additional networks/protocols like IRC, MSN, XMPP, Yahoo Messenger, etc over the next few years.
This is important because the internal API in the program was designed to handle these protocols and these protocols were much more simple than the protocols we have today feature wise.
At any rate, these APIs remained in place for Gaim 1.0.0 and became part of our stable API and remained through the naming dispute to become part of the Pidgin 2.0.0 API.
If you're familiar with Semantic Versioning you understand the basic rules of L versioning that we must adhere to for libgaim in the 1.x.x series and libpurple for 2.x.x series.
What this means is that we can't change any existing API without bumping the major version number which would cause lots of work for consumers of libpurple as well as plugin authors. So, as you may have guessed, we didn't take bumping the major version number lightly.
When it finally came time to bump the major version number we threw literally everything we had at the time into the mix as well as a bunch of new Google Summer of Code projects as well.
One of the biggest offenders here was an initiative we named "gobjectification" that I was pushing very hard. GObjectification was to update libpurple to use GObjects for all of our internal data structures. There's a lot of justification for this, but it's really out of scope for this post so we'll maybe cover it later in another post.
The biggest issue with gobjectification was that it needed to touch just about everything in libpurple. It got so complicated that I even wrote a DocBook to document it.
There were even two Google Summer of Code projects dedicated to completing the process. Eric Polino's 2009 Struct Hiding and Gobjectification project as well as Ankit Vani's 2013 GObjectification project.
As you can see four years elapsed during this time of trying to get it finished, and while most of it was done, it wasn't actually in a release-able state. This was also the time frame where I was on hiatus from the project as well, which is a topic for another post as well. Unfortunately, that's pretty much where gobjectification sat on the 3.0.0 branch until I took the project over in 2016.
That means from 2009 to 2016 our 3.0.0 development branch, the branch were all API changes could happen, was locked up in development hell. And in that time frame the chat landscape changed quite drastically.
It was during this time that Hipchat, Slack, Matrix, and Discord were all starting to gain popularity and adding all sorts of new features to chat.
Most of these new features had been added in some regard to XMPP, but we hadn't implemented many of them because we couldn't easily do so due to our API lock-in.
For example, message redactions (editing/deleting) couldn't be implemented because way back when we created these APIs messages didn't have unique identifiers which are necessary to find the existing messages so that they can be edited and deleted.
More specifically, those APIs passed both the message and its author around as strings to the user interface for display and the logging API for storage. While the logging API did provide a keyword search, there was no other way search for a message and literally no way to modify an existing message, let alone update an author's username.
So even though gobjectification was merged and mostly complete we literally didn't have the API handle modern chat features. So if we were to "release what we have" we would be releasing a major version that can still only implement all the features of the previous release.
So fixing the API to handle all of these new features means updating and creating new APIs for messages, contacts, logging, status, and many other systems. These API updates are all intertwined into all of not just libpurple, but Pidgin, Finch, all the plugins, and anyone else using the library.
This means we've had to be very careful about how we design and implement these new APIs as well. Basically we'll create a replacement API in libpurple and write unit tests for it to confirm it's functioning as intended. Then we will start porting everything else to that new API. Sometimes this even includes a migration API to help move things along.
Regardless, all of this takes a lot of time and effort, and has been our primary focus for a while now. Currently we're replacing the Buddy List APIs with the Contact API and we're also replacing the Status API with the new Presence API. This has been a multi-month project and the end is near, but not quite known yet and these two new replacement APIs are required for features in the first alpha.
What this really comes down to is that we might have been better off starting over from scratch, but libpurple is not a small library, so starting over means a long time to a MVP as well. Call it sunk cost fallacy if you like, but doing things incrementally here does keep us with a semi functional application in the mean time.
I hope you're enjoying these posts! Remember they go live for patrons at 9AM CST on Mondays and go public at 12AM CST on Thursdays! If there's something specific you'd like to see me cover here, please comment below!
Top comments (0)