One Backend fer 'em all

I had always looked at Ubuntu's 'Add/Remove Programs' app (gnome-app-install) and wondered whether it would ever become cross-platform and bring its unique simplicity to other desktops. Then, a few days ago, I came across PackageKit on #gnome-journal. At first I could not believe what I was reading, the cross-platform application installer I had always fantasized of was here at last! Over time, my enthusiasm faded.

Discussions with Necoro on #gentoo-guis caused my opinion about PackageKit's awesomeness to lessen as I realised that in its current state, PackageKit's simplicity undermines the main feature of Gentoo -- choice. There is currently no way to map USE flags to PackageKit's UI or its backend (although I think it could probably be abstract-ised in some way). Gentoo without USE flags is... what can I say?

It was after this discussion that Necoro came up with this brilliant plan of having one backend to support all the GUIs for Package Management in Gentoo. He then emailed a couple of people and posted his ideas on the gentoo-guis Mailing List.

His basic idea is that GUIs should be able to concentrate on getting the UI right and not having to worry about the talking with Portage/Paludis/pkgcore part. They all do the exact same thing there anyways (though some disagree ;), so lets save a lot of duplicated effort and give them One (highly optimised) Backend which they can all use, and after that they can happily concentrate on getting the UI to "Just Work" or whatever :)
Another big advantage of this is that any GUI using the backend will then support _all_ the Package Managers supported by Gentoo, a very desirable feature.
Its a great idea, and the architecture for it started out in a DBus-fanboyish style ;)

Package Managers
|
(bindings)
|
V
Provider Daemons
(in the same language as the Package Manager)
|
(DBus)
|
V
Backend Daemon (Python)
|
(DBus)
|
V
GUIs (Any Language)


This kind of crazy architecture was "envisioned" as a solution to the multitude of languages that were being used to make the Package Managers (Python, C, Perl) as well as the GUIs (Python, C, Haskell). Then, araujo brought us back to our senses by thumping us on the head with the proverbial `C_bindings_dammit!` hammer :)
The architecture then transformed into the much much cleaner

Package Managers
|
($lang-to-C Bindings)
|
V
Backend Daemon (in C)
|
(???)
|
V
GUIs (Any Language)

And so we come to the point of debate, namely, (???). Should the interfacing between the Backend Daemon and the GUIs be via bindings (in the same way as with the Package Managers), or should it be via DBus?

Some points in favour of bindings:

• No need for a daemon backend process


• Probably Faster


• Might be easier to integrate into existing GUIs

The points in favour of DBus:

• Interface/Communication becomes very simple due to the nature of DBus. Its communication based model means things can be kept abstract, slim, and trim ;)
  (for an example, see the DBus interface of packagekit)


• Now that the communication is completely clear, making UIs for it becomes easier, For an example, see this Ars Technica article on DBus + Pidgin.
  Another example would be a (almost trivial) systray applet which could notify you of new updates :)


• And then, best of all, integration with other apps (like beagle -- tell it to not index when emerging, or deskbar -- install an application by typing its name) becomes possible and opens so many channels of opportunity.
  


• Plus, DBus just sounds so darn cool =P

All in all, I'd like to propose the following architecture, which could also - with some work - accommodate itself as a PackageKit backend interfacer for _all_ the Gentoo Package Managers at once :)