So far other two weeks are past since my last blog post about Rigo. I have been able to implement several features since then, mainly thanks to RedBull I’d say. Jokes apart, I’m used to work on Rigo in the evening and early (6am) morning and, despite hackers are all used to nightly coding marathons (including me, actually), the best is coming out of me when birds start singing.
git-log would tell you what changes have been made in this timeframe, without me wasting time here instead of coding, but I think communicating it explicitly would help me getting some feedback from all of you in order to enrich my next UI design iteration. I’m not an interaction designer myself, don’t really want to be, but I learned a lot of things working with them in the past. Although we sometimes see interaction designers as kids with a pencil abusing of erasers (i’m not serious!) they are vital in the success of your App (I learned it the hard way as well).
RigoDaemon is the new Dbus-powered service that handles the privileged operations on behalf of (concurrent) Rigo clients, such as Repositories Update, Application Management (install/remove/update) and System Upgrade. These are in fact the three main tasks RigoDaemon is going to carry out. The hard part has been implementing a way to do Resource Passing from Rigo clients (holding shared Entropy Resources locks) and RigoDaemon (wanting to acquire exclusive access to the same Entropy Resources), i called the whole process: rendezvous (as it is, in fact). The rendezvous has to be fault-tolerant in the sense that, being for both releasing and acquiring back shared locks by Rigo clients, these can go away anytime and RigoDaemon is required to make sure to not hold resources if no Rigo instances are connected.
RigoDaemon is going to replace Magneto Dbus Service, once Rigo replaced Sulfur.
Multiple Rigo Clients can be used concurrently, as images show below. The IPC architecture allows RigoDaemon to “arbitrate” resources access, kindly asking all the clients connected to release them for example (due to the beginning of a specific Activity, see below). At the same time, it is possible to launch an activity (like repository update or system upgrade), then close Rigo, reopen it and have it resumed to the current activity state. This makes Rigo fully fault tolerant against bugs and critical system updates where GTK3 or other Rigo dependencies could (but shouldn’t) be subject to potential instabilities. Running GTK3 unprivileged is also another indirect goal achieved.
Both RigoDaemon and Rigo implement their daemon and UI state through a Finite State Machine, moving from an activity to another atomically. This makes possible to aggressively use multithreading without worrying too much about UI state and the likes. I don’t want to start describing the boring details here, but since I introduced this way of seeing the whole User <-> Rigo interaction story, everything started to make sense: spawning a repo update event now means “hey, i want to carry out this activity, gimme the UI control” and “hey dude [dude is another Rigo Client process] the other guy here wants to do Activity-X, could you please lock down and start listening to his events?”.
The concept is the same you can find developing for Android, and is about how the human being can deal with tools, you cannot use a hammer and a chainsaw at the same time in real life!
Any privileged activity inside RigoDaemon is controlled by PolicyKit actions. There are three main actions (the same listed below): Repository Update, System Upgrade and Application Management. This way administrators could even setup policies allowing users to update, upgrade or install apps with no privileges at all (read: *could*). PolicyKit gives us this fantastic flexibility though.
The Activity I’ve been working on is Repositories Update. Even if this is usually carried out by Magneto (automatically updating repositories on our behalf), there are cases in which this is still important for Users: they might not have Magneto loaded, repositories could have been just added to the list and Rigo would need to download them, etc.
This Activity is also a good testbed for RigoDaemon <-> Rigo Client IPC architecture. Fact is, it took me 5 iterations before getting everything working the way I wanted (I’m a picky guy you know…).
Repositories Update Activity, like all the other activities that are going to be implemented soon, require RigoDaemon running. Now, there’s a trick to start it in devel mode, and start Rigo (you need pygobject-cairo, all the GLib introspection stuff, including introspection support in policykit):
$ git clone git://git.sabayon.org/projects/entropy.git
$ cd entropy/rigo/RigoDaemon && sudo sh devel-start-daemon.sh &
$ cd ../ && python2 rigo_app.py –debug
The UI is not 100% complete first of all.
System Upgrade, Application Management activies are not implemented yet.
The Rigo Preferences View is not there (this will contain handy buttons to launch secondary activies as well as forcing repositories to update).
If all goes well, I expect to have everything working in a month from now, even because I need to go back studying then.
This blog post took me 1 whole evening (split across several), if you think it’s been worth it, don’t think twice and donate to Sabayon now, http://www.sabayon.org/donate .