Boy, Facebook sure knows how to make money.

Taking advan­tage of the fact that people like to receive gifts, Facebook has this feature whereby anyone can send a ‘gift’ to any of their friends. A gift, it turns out, consists of a little icon with a personal message attached to it. And it costs real money to send one.

Ever had someone tell you that instead of buying you a gift for your birthday, they were giving it away as charity? That wasn’t…fun, was it? Now imagine that instead of charity, they gave it away to Facebook. Here is some cash Facebook, so that my dearest friend gets a silly little icon as a token of your appre­ci­a­tion. Lame.

I like to keep my software up-to-date, so I sync it with the repos­i­tory every day, and see if there’s anything that needs updating.

And yet, I don’t like the fact that it takes time to perform the update, or that there is a chance that my stable system could be broken by the change, or that a package may fail to build.

So I run the update command, hoping that there’s nothing new.

The wait is finally over. KDE 4.1 is now in the official portage repos­i­tory, which means that Gentoo users can upgrade to it without having to unmask any packages or setting up an overlay.

I upgraded to the new and shiny KDE 4.1 today for the first time. I could have easily gotten it from an overlay a long time ago, but then I figured it was best to wait for it to mature. Like its prede­cessor (KDE 3.5), this version of KDE looks quite unpol­ished until you spend some time customizing it. For instance, I cannot fathom the reasons behind not enabling font anti-aliasing by default. Without this tweak, all fonts look jagged and ugly. KDE also seems to have taken the path of Microsoft’s Windows Vista in terms of its color scheme: gray and black seem to be the norm.

Overall, I am not too disap­pointed with the upgrade, but I realize now that I’m going to have to wait for future releases for many pieces of function­ality that I used to love in KDE. This is one of the downsides of having software redesigned from scratch. For instance, Amarok 2 (still in beta) included in this version of KDE, is missing several key features, such as track-queuing and equal­izer support. I just wish the KDE devel­opers had focused on having a 4.1 release that was on par with 3.5.10 in terms of features, rather than worry about the details.

A useful paradigm that should be consid­ered when a stateful software system is to be designed is idempo­tence. Leaving aside its exact defin­i­tion in mathe­matics and computer science, idempo­tence can be roughly described as a system charac­ter­istic whereby, calling an opera­tion multiple times is equiv­a­lent to doing it exactly once.

For instance, setting the value of a variable X is an idempo­tent opera­tion, because setting its value to be Y several times has the same effect as setting it just once. On the other hand, incre­menting its value is not an idempo­tent method because the result depends on the number of times the opera­tion is called.

Imple­men­ta­tion

Before delving into why you might want to have idempo­tence, let’s have a look at how it can be imple­mented. One way of doing it is like this:

Design a state machine

A state machine identi­fies every unique state that the system can exist in, with a clear indica­tion of which states the system can transi­tion to from any given state, and under what conditions.

Design a minimal API

An appli­ca­tion program­ming inter­face is the gateway for external systems to interact with the service. We start by designing a minimal API, identi­fying all the methods that could change the state of the system. It is best not to clutter the API with non-critical methods at this stage.

Expressed differ­ently, an API method repre­sents a single transi­tion in the state diagram. For example, a system could have states such as Ready­ToP­ur­chase and TaxAdded. The addTax() method, if successful, provides the transi­tion from the first state to the second. This method can never be applied a second time, because by then the system has already moved on to the next state.

An impor­tant restric­tion on the API is that if the state has some attrib­utes, they must be maintained metic­u­lously and checked against incoming requests. Suppose the addTax() method takes a parameter called amount. If the method is called again with the same amount, then the expected response is success, since the system is indeed in a state that the function call was supposed to move it to. However, if amount is different, then the response should be a failure, or at least some kind of partial failure — other­wise, the client will assume that the new tax amount had been added. A state should never change its internal attrib­utes once they have been set.

Transi­tions should be atomic

It goes without saying that transi­tions need to be atomic, so that multiple requests do not corrupt the state while the system is transi­tioning. This can be achieved easily by acquiring a lock on a mutex at the start of a transi­tion, and releasing it on completion.

Why Idempo­tence?

Naturally, it is a good idea to ask why we are putting in so much effort. While this may seem inordi­nately complex at first, you will soon discover that such a design actually simpli­fies the system tremen­dously when there is a great deal of concur­rency. When there are a large number of processes or threads commu­ni­cating with each other and the number of messages exchanged is huge, idempo­tence provides a guarantee of sorts about what the system can or cannot do. The state machine approach allows you to simply worry about the system in its current state, rather than the system as a whole. As a debug­ging technique, the devel­oper simply needs to say, “This was the previous state A, and now it has moved into this new state B — what combi­na­tion of parame­ters caused such a transi­tion?” Idempo­tence makes this approach even more robust, ensuring that the system works in the face of message dupli­ca­tion and errors.

This robust­ness also allows the design to sacri­fice a reliable commu­ni­ca­tion layer in exchange for speed. For example, TCP (which has a larger overhead) can be replaced with UDP, since the appli­ca­tion is resilient to message loss and duplication.