Roight.

An amazing Antaragni just got over, and the semester-end is just around the corner. This kind of thing usually brings about two mixed feelings - the tension associated with the End-Semester exams, and the holidays that follow the aforementioned ordeal.

How would I rate this semester? If you asked me to describe that in one word, I would quote Zero Punctuation and "tell you to stop being such a twap", but if pressed (and I'm plagiarising off of him again), I think I'd go with "Schizophrenic" "Inconsistent".

The semester started off with me boistering with confidence that I wouldn't screw my acads this time again, but I ended up doing that anyway, and in some ways, worse than I had ever done before. However, unlike the previous times I had done so, this semester wasn't fraught with guilt or sadness for me, and on the contrary, this could've been said to be my best semester yet if I hadn't kicked college education in the nuts again. And this is why my first semester remains to be my best semester here yet.

"What could possibly alleviate sucky acads?" you ask? Well, I can tell you it has nothing to do with "love", so you can take that thought out of your mind and stuff it in a sticky petri dish in a dumpy lab in Indonesia for further perusal on students who have a ratio of girls higher than 1:50 in their college.

Roight.

Now that we have that clear, lets see what made me happy this semester. To be frank, I don't really remember, and my memory of most things before my trip home is incoherent to say the least. One plausible theory is that I reset my memory to forget the unpleasant things that happened to me before my vacation, and now that I dig deeper in my head, I feel bubbles of despair bubbling up again.
Hush. Lest the bubbles grow.

Lets look at what all I can remember without disturbing those friendly-bubbles (yes, they are friendly, even if not in the short term).

Good news:

• I'm a Beagle developer now~! Thanks to Arun Raghavan for first introducing me to Beagle, and getting me interested in it, Debajyoti Bera for constantly encouraging me while working with him on Beagle's fancy new webinterface, and Kevin Kubasik for giving me my first boost into Beagle while working on Beagle's Ubuntu Gutsy packages :)


• gnome-system-tools is (mostly) working on gentoo again! This is thanks to eva (gentoo's gnome herd) and garnacho (system-tools-backends' maintainer). I didn't contribute any code, but the fact that I was there to witness its development (and help in some testing), gives me joy :)

Laziness news:

• I've been too lazy to work on the article for Gnome Journal even though I've promised the editors at least one article for the next issue :(


• After making strides with Necoro on #gentoo-guis on Catapult, I sorta drifted off for a while (thanks to my vacation and Antaragni), and I haven't really thought about the project, not looked at the code, and not even contacted Necoro...


• I had said that I would be working on a Gentoo backend for PackageKit, but I haven't done monkey balls in that direction :|


• Slacked off testing/helping out in the stabilisation of the now ~arch GNOME 2.20 in gentoo..

And I'm too tired/sleepy this evening to catch up on these right now. And the cold I have isn't helping either :-/

Monstrously hungry as well; time for dinner.

Maybe tomorrow will be more conducive to fix my acads and my laziness (It'd better be. English assignment due on Wednesday).

Webbeagle, TheOneBackend, PackageKit, and God

1. Read about Webbeagle.


2. Read about TheOneBackend


3. Read about PackageKit


4. Read about God.

1. => dBera's illegitimate child, and something I have been hacking on for the past 2 weeks.


2. => Necoro's illegitimate child, and something that will be hacked on in the future


3. => Hughsie's illegitimate child, and something I will be writing a portage backend for.


4. => A very interesting way of looking at everything.

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 :)