...that's what my friends all call me.

Actually they don't but since I am a huge fan of Lynyrd Skynyrd and this blog entry is closely related to the previous one I am (ab-)using yet another of their song titles.

Earlier this week I got rid of the "org.kde" namespace in Akonadi's D-Bus names, e.g. org.kde.Akonadi.Resource is now called org.freedesktop.Akonadi.Resource, to emphasize that we are a cross-desktop project and that the real interaction point for interested parties are the interfaces (and the data transfer protocol), not some specific implementation like libakonad-kde.

Speaking of renaming: I am not yet quite satisfied with one of our D-Bus names, so if you have any suggestions I'd like to hear them.

To further facilitate contributions outside the KDE sphere we have requested project infrastructure on freedesktop.org
Since this will take a while, let all any interested contributors know that getting commit access to KDE's SVN is not an arcane procedure and anyone with a proven track record on another free software project will most likely get approved quickly (I am talking about the order of minutes here).

I have had so much struggle finding a decent html editor that I finally wrote one on my own:

• mozilla composer cannot handle the fish://-protocol
• openoffice dito
• quanta crashes when it sees me
• I finally started using kword, which cost me several months of fighting and finally even contributing code, but there are too many problems for using it where I work.

Collaboration

I am pleasantly surprised to hear from Aaron Seigo and others that there has been more collaboration going on that most people might not know about. Learning that Qt 4.x now can use the Glib event loop gives us a lot of abilities to create glue between KDE and GNOME interfaces which is really encouraging.

Lynyrd Skynyrd rocks, but you already knew that.
Will Stephenson rocks as well and you quite likely also already knew that.

Free Bird is one the reasons why Lynyrd Skynyrd rocks and one of the reasons why Will Stephenson rocks is that he took over the gargantuan task of moving the Akonadi server to is KDE independent location in kdesupport.

"Gargantuan". You know, I've always liked that word "gargantuan", I so rarely have the opportunity to use it in a sentence. -- Elle Driver (Daryl Hannah) in "Kill Bill 2".

Usually moving code in a SVN repository isn't that hard, but although we were very thorough about not getting KDE dependencies into Akonadi server, a lot of its build system related things were.
So making Akonadi server build again in its new location and making Akonadi dependent code in kdepimlibs and kdepim build again was truely a gargantuan task (twice in one blog entry, not bad).

Additonally, several other developers, including Mr. Buildsystem Alex Neundorf, have done some cleanups and thus further improve Akonadi's cross-desktop characteristics.

We still need to clean up some KDE name references, such as D-Bus names, etc. and setup project infrastructure on freedesktop.org, but I am quite confident that this won't take a lot of time. Until then, meet us Akonadi developers on IRC channel #akonadi, freenode network.

Other mentors have already blogged about their GSoC projects, so I am going to do the same for Akonadi.

Basically Akonadi got three slots from KDE and one from OpenChange.

Lets start with the one from OpenChange: Brad Hards will be mentoring student Alan Alvarez, who's goal is to implement an Akonadi resource based on the OpenChange MAPI library.
If he succeeds it allow Akonadi and thus all Akonadi-enabled clients, to access mails, contacts and calendar items stored on a Microsoft Exchange server, using the same access mechanism as Micrsoft Outlook, i.e. not requiring that the Exchange administrator enables any additional transport such as OWA

The first of the Akonadi GSoC projects hosted by KDE is a RSS framework for Akonadi, where student Dmitry Ivanov is mentored by Akregator maintainer Frank Osterfeld.
The goal of this project is to have a central service for aggregating news feeds, so applications like Akregator or KNewsTicker can access the same data without requiring them to implement article transfer and storage multiple times.

The second project is by student Igor Trindade Oliveira and he will be mentored by me.
Igor's plan is to implement a test framework for Akonadi, so that resource developers like Alan or Dmitry, application developers like Tom Albers and the Akonadi team members can more easily run tests on their creations.
Currently running reproducible test scenarios requires to manually setup a clean test environment, manually start the required set of processes, manually manipulating files or remote storage, manually... (I guess you get the picture).

One of the probably most interesting parts from the point of view of a larger audience will be the possibilty to script Akonadi data processing through a Kross bridge, which might also be useful for developers and power users of Akonadi PIM applications.

The third Akonadi related project is officially about modernizing KPilot where student Bertjan Broeksema will be working under guidance of mentor Jason Kasper. I am blogging about this because syncing of PIM data will using Akonadi on the sync's desktop side.

Like all other KDE subprojects we got a lot more good proposals than we had GSoC slots for, for example three very good applications for implementing an Akonadi resource which uses Google's data API to transfer data from/to Google's web-based PIM apps.

I've just published the Building KDE on openSUSE guide over at the openSUSE wiki. It makes it insanely easy to build latest KDE 4.1 in a minimal number of steps, but the goal is not just to make it easy, but to give people the tools and the skills to go from just building KDE to developing it. If you're the type of person who always stays up to date with the latest alphas/betas, or are a Power Bug Reporter who wants to report bugs with full debug output and maybe try applying a patch from a developer or twiddle a few bits yourself, this is a way to get the freshest KDE 4 Plasma or Amarok around.

The guide uses Qt 4.4 and the kdesupport packages from the openSUSE build service so you don't have to build them yourself. The openSUSE KDE Team are so obsessive about keeping those packages up to date that the only way to get them fresher is to smuggle yourself into Trolltech (I hear the big N810 disguise works). So there's no need, if you want to work with the main KDE modules or extragear, to build those yourself. For the record, with a 4 year old HP zt3000 - Centrino 1.5Ghz, 512Mb RAM - laptop, I was able to build a minimal KDE 4 desktop in 4.5 hours.

And if you run into any problems or have feedback, talk on the Discussion page attached to the Guide or look for 'wstephenson' in #opensuse-kde on Freenode.

So after a few emails of feedback on MyPoint i have made a few changes and updates to the tool.

The big change is that I changed the wiki formatting to trac's flavor of markup. While I don't like it's flavor as much as say media wiki trac is what I use at work and play. The major gain of this that it is easier to collaborate on content with coworkers. Since MyPoint's focus is to make it easier for developers to make presentations with developers tools I thought this was a wise choice.

Based on reactions to my previous blog entry I'd like to add a bit of context regarding the GSoC idea of implementing a GLib/GObject based client library for Akonadi.

The whole architecture of Akonadi is based on the idea not to depend on any specific library but to make the data storage access protocol, and D-Bus for out-of-band notifications, the only requirements for clients.
Learning from the non-adoption of DCOP and KIO, both also out-of-process service infrastructure projects, due to the lack of visible alternatives to the respective KDE based client libraries, the developers of Akonadi acknowledge the need to at least a second, independent, client library implementation.

This could of course be done in Java or Python, but since the GLib software stack is one of the two main stacks for Free Software desktop applications, it sounds a lot more reasonable to use it for the first of hopefully many means to access data in Akonadi.

Some people understand this to attempt replacing the Evolution Data Server.
Of course a GLib/GObject based client library for Akonadi would make it an second option for application developers on that software stack, but I am pretty sure that the EDS developers have enough confidence in their technology to not be afraid of the partial overlap between the two projects.

But just in case they want to strengthen their position and are looking into hosting a GSoC project for developing a Qt/KDE based client library for EDS, I'll be available as a co-mentor on Qt/KDE specific issues.
Btw, for this is would be great if the EDS maintainers could put the D-Bus based communication back on their roadmap.

Since the Akonadi related applications for GSoC so far have been mostly about interfacing with external PIM data storage systems, e.g. Google's web based apps, I'd like to a bit of advertising for two other things we'd really like to have somebody working on.

The first one is the test framework idea I added to our list (second item). True, testing and stuff related to testing are usually quite boring, but it is nevertheless necessary and would be a great help for any one working on or with Akonadi.

To not leave the fun aspect out of the equation, one idea how to implement it would be to create a pair of scriptable Akonadi Agent and Resource, e.g. through a Kross plugin, effectively making it possible to work on Akonadi managed PIM data from any language Kross has support for.

The second project I'd like to get more widespread publicity is basically a matter of extending the target audience by getting support for developers on other desktop environments or tool stacks.
The idea is to implement a GLib based Akonadi client library, i.e. an GLib equivalent to KDE's Akonadi client library libakonadi-kde.

Unless other KDE related GSoC projects this would not require C++ and Qt skills, but rather C and GLib skill.
Till Adam would be available as a mentor, though we would really also have a GLib expert as an additional co-mentor or advisor.

Any student interested in either project can contact us on the kde-pim mailinglist or on IRC channel #akonadi on the freenode network.

I've received 2 emails asking for more blogging and info about current klik2, especially since FOSDEM 2008.

Unfortunately, I don't have much time these weeks for 'FOSS-work', due to pressing 'work-work' duties. Since about October, I'm entangled deeply (too deep, if you ask me) in a major project that leads me to spend 5-6 days a week in Frankfurt (250 km away from home), with 12-14 hours a day on a customer site. Now compute: how much time does that leave me on evenings (in the Hotel) and weekends (at home), given that one-way travel time Stuttgart <=> Frankfurt is about 3 hours, and daily travel time inside Frankfurt is about 30 minutes?

This project takes much longer than initially thought. (Also, it involves only a very little bit of Linux, Solaris and Open Source, and much more MS Windows and proprietary software.) However, now there's the first light at the end of the tunnel. A few more weeks, and sometime mid-May my routines will be back to more normal.... *sigh*.

Anyways, while there are some more current klik2 development news, here's just one item for now: GSoC!

The klik team has submitted to become a mentoring organization for the Google Summer of Code 2008. If you are interested in some of the possible student projects, visit our GSoC idea's page.

We give a short description of each idea, as well as listing required skills and expected difficulty level to implement it, the programming language to use and some reference links to study:

• klik2 Updater
• klik2 Security Framework
• Enhancement/Replacement for fakechroot
• Packaging the klik2 client
• Porting klik2 to *BSD and Opensolaris
• Automate klik Recipe Testing
• Replacing Server-side APT with Server-side Smart