A rather constant theme recurs in many blog posts and forum threads. Often the statements in question are factually correct but, I think, miss the nuances of the cost involved with each choice. These themes are often framed along the lines of:
- AWN is more stable than xyz.
- Why doesn't awn have shiny feature like the parabolic zoom in abc?
Some might disagree with me but I actually think these two statements are two sides of the same coin. And it all comes down to how applets are handled in AWN versus some other docks.
There are fundamentally two approaches that can be take to applets.
- Everything, including the dock and all the applets, run in the same process space.
- Every applet runs in a separate process space and the dock itself runs in a process space of its own.
Now in reality it is possible to mix these two approaches. And at the moment AWN does just that; the core taskmanager/launcher applet and the separator applet are not really applets, instead when they are in the applet lists it activates code running in AWN core. This will be changing with the 0.6 release of awn when the launcher/taskmanager code will be officially moved out of AWN core into applets. (Yes I have been working on an experimental implementation of this already... but it is experimental). Obviously, some of the other docks choose a different path.
What are the tradeoffs:
- If everything is running in the same process space it's much easier to do bling. It's possible to easily and efficiently toss cairo surfaces (for example) around in a nice and shiny manner:-) In AWN's situation each applet(process) has it's very own window which makes it far more difficult to perform certain types of magic (yes we know many of you want a parabolic zoom... but it's hard, though maybe not impossible, to do with this architecture). Basically, unless we implement some compiz style window based effect engine it is necessary for each applet to handle its own effects though coordination is possible through IPC (d-bus for example), and this is what we are doing. (yes there are plans to improve this.. we have not reached the limits of bling possible)
- Separate processes mean more stability. If programmers were perfect this wouldn't be true. But programmers are not perfect. By separating each applet into it's own process space it makes it very unlikely that an error in one applet will bring down the whole house of cards. A shared process space situation tends to be a lot more dodgy. On the same note it makes it easier for applet devs to contribute. It's all about a low barrier of entry and there is a fairly low barrier for AWN applet developers... you don't need an indepth understanding of the internals of AWN to write an applet for it.
- A single process uses less resources. Even though the additional resource usage of multiple processes might not be as great as one would think, it can still be a significant cost. In the case of AWN I would have to say you pay a cost of a bit over 1 megabyte for each C applet versus a situation where everything ran in the same process. And that is a best case number.
- One process per applet lends itself to allowing a diverse environment for developing applets. Currently AWN supports C, Vala and Python applets and it lends itself well to the addition of others. This attracts applet devs. The more applet devs the more applets you get. And applets are good.
So, it really is a case of tradeoffs. I won't say with certainty which ones is the best choice... it ultimately depends on the user in question.
