Will's second talk - pimping PIM

Apparently I'm a huge fan of Will, as I also made notes of his second talk about Akonadi and pimping PIM. It's rather unfortunate some guys who were interested in his talk didn't come, but at least I enjoyed it.

Starting with the history of KDE PIM, he explained how the hackers want to go from a very monolithic infrastructure in KDE 3 to a much more modular and flexible system in KDE 4. Akonadi will be that new infrastructure. The way KDE 3 handled data wasn't scalable, and in these days of huge social networks and all kinds of online and offline data you need something which can adapt to any new kind of information easilly. Something which can be used by the whole free desktop - a clean seperation of UI and data, caching, sharing and easy synchronisation. Akonadi will make it easier for application developers to access and combine data, thus allowing new and innovative uses of knowledge and information on the Free Desktop.

Further Will went into some more specific details of the Akonadi design, explaining the choices which were made. For example, they choose to use IMAP as the main protocol for the movement of data instead of DBUS mostly for efficiency reasons - DBUS is used for controlling the Akonadi server, though. Akonadi is entirely type independent, and features a smart cache for remote data with change notification and conflict detection. So, you can store anything you want, work offline with your data, your applications are always up-to-date and Akonadi also ensures the integrity of your data.

And of course - as Akonadi will be here soon, Will gave some pointers about how to use it and the roadmap for the future. There is a developer preview available, so it's time to start having a look now... The Akonadi developers are looking for someone willing to write glib/gtk bindings so the cross-desktop part can get started, and of course there are many other things which could be written. One can clearly see Akonadi fits in the KDE strategy of enabling more innovation and thus serving the Future of the Free Desktop. I can only say 'great job' to the KDE PIM developers!

Valencia

So, it's time for a blog. I'm in Valencia (Spain) right now, lying in the grass, enjoying the last rays of sunshine.

Me outside. Ignore the kind-of agressive look, it's just the sun in my face. I'm really a nice guy, really...

I can say Valencia is one heck of a city. Beautiful women (yeah, what's on a man's mind?), beautiful weather. The people are very nice, and they have some pretty amazing buildings out here. I'll go and make a few pictures tonight, but they won't really capture the sheer size and beauty anyway, so I won't bother posting them here. I can and will bore my parents with them, though ;-)

Meanwhile, Guademy also rocks. They've put me with a Gnomie in a hotelroom, a very nice one I must add. The conference is also interesting, even though many talks are in Spanish (Saturday was better in that regard).

This was good food...

Last night, we went out for food and after quite a walk (more than an hour in total) we got to the most insane restaurant you've ever seen. As my Brittish roommate said - the total randomness of that place is disturbing. It started with the peanuts... A guy game with a bucket of peanuts, throwing them on the table with a large spoon. We were kind'a surprised, but they just got started. The dishes were also thrown careless on the table, and you had to use a mug to get the sangria out of a baby's potty... Everything was silly, complete with penis-shaped bread (with a complementary guide on how to slice it), weird combinations of food and when they threw the spoons for the desert from the bar onto the table (that's at least 5 metres...), we thought we had seen it all. Nope. They finished the dinner with a large bottle of champagne with a penis on it, topped with whipcream (?!?). They made one guy swallow the penis, then made it 'cum'... You should've seen it. Of course they picked one with a beard so he had cream all over his face, and the champagne spat all over the place. Wicked cool. I don't think a place like this would work in the Netherlands, they're taking it pretty far - but it's perfect for a bachelors' party. By the way, despite the fact I said to the organizers I believe them when they say this restaurant isn't typical for Spanish people, I do think the average Spanish person is at least slightly disturbing :D

My slightly disturbing Gnomy roommate on the right, a way more disturbing French Gnome Releasemanager on the left.

Back to the conference - they made me gave my talk twice - so I had a live audience to practice for the first time. Used Will's laptop, which is much faster when crashing KDE 4.1 Alpha 1 ;-) It went pretty well, except for me totally forgetting to do something with the cooperation theme - I only thought about ways of doing that after I gave the talks.

Oh, and for those who so kindly care about me having to use my incredibly slow laptop with the loose battery - I managed to fix the latter issue with some tape. It doesn't shut down randomly anymore, makes it much more enjoyable. It's still slow, of course, but I can live with that until I buy my own EEE PC or whatever equivalent ultra-portable.

As I didn't manage take notes, no real articles from this event. I did take notes of one of the most interesting talks by two Novell employees, Will Stephenson and Rodrigo Moya about their experiences with cooperation between our two desktops. So, here you go, enjoy...

We can do more together - duplicating code wastes time and resources. Besides, it makes it harder for third parties to decide what to support or use, and it makes the linux platform seem fuzzy. When making a choice, you have to take into account many issues, and currently you can't use a best-of-breed policy. Finally but maybe worst, there is also a lot of duplication of data required or used within these applications as well. Concluding, when you've got shared implementations for software, you can develop new features faster, have more stable software and make it easier for 3th party developers while giving users a less hard time as well.

The current situation is that we do share several things, but at the same time still duplicate many others. If you save a password in the Gnome-keyring, you will have to enter it again to ensure it ends up in KWallet. Luckily, icons and MIME types are shared these days, as wel as technologies surrounding fonts, the systemtray and pdf reading. For the future, there are plans to solve some of the still existing issues. A shared keymanager will make life easier for users, and so will a shared sessionmanager which allows restoring the state of applications next time you log into your desktop.

Now Rodrigo went into the specifics of sharing - why would you want or do it? How important is it? There are of course the obvious reasons: developers are spread thin over the huge codebases. Meanwhile, users demand more and more from their software. As the relative number of technical users goes down, users expect more stability. Enterprise users demand very specific features and migrants from proprietary software want their new software to do what their old software did. They aren't used to the perpetual state of development we know in the Free Software world. So things must change somehow.

Currently, the playground for standardisation is far from perfect. Some projects at freedesktop.org are pretty successfull like HAL, DBUS, Telepathy and the XDG-utils. But other projects didn't turn out incredibly successfull - sometimes it's just too much work to share things. Stephen argues sharing should start from the beginning. The right people should be involved from the start - developing something for one desktop, then throwing on freedesktop.org and call it a standard doesn't work.

The biggest limiting factor seems to be lack of awareness of each others technologies. Often, the knowledge is out of date or just too limited. Better documentation and pointers to the right people would make a large difference. Currently, developers' awareness of the technology from they other project is non-existent or outdated, and interaction often happens just by chance. Equivalent peers working on similair projects should strategically be brought together somehow. Meetings like Guademy could be used for that, but also the normal hacking sessions might be a place to start.

Stephen has some ideas where we need to focus on, based on some heuristic questions like wheter the functionality is already implemented (and how) or if it is about UI code or not. Sharing boring stuff like how to talk to flickr is the way to go here. Focus on things you can factor out in a separate library.

Of course, there are different ways and levels of sharing. For example, you can build upon a shared library. On the other hand, you can have a common specification but have codewise totally different implementations. Or just use the same data. Or even only share some policies. It is important here to not go and try to share toolkit-level stuff, but focus on framework functionality.

Currently, there are several bariers to sharing - but most of them are psychological, not technical. Not liking C or C++, thinking bad of glib, (often bogus) licensing issues - these should be pointed out and debunked. Luckily, there are several very successfull projects we can point to as proof sharing works. We can examine them to find out what does and does not work. As mentioned before, the split of UI and the underlying technology is what made Poppler and Webkit popular We need to find the lowest common denominators in terms of functionality to identify what to share - and it works. Of course there ARE technical issues - if you want to share something, it often can't depend on the libraries you are used to work with. That does mean more and more difficult code to maintain, so you should carefully think about what and when to share.

Now Rodrigo went into some specific ideas to make sharing easier. There are some infrastructural things we can do to share more. For example, synchronising desktop release dates would make a big difference. We could of course start by having a shared release/roadmap for the shared projects, and as KDE is also going for 6 month releases now.

A next step would be to improve the sharing of data. We've done icons now, but for example the default locations for music and documents are still defined by distributions. Sharing webbrowser caches and metadata is still far away - but would make life easier for users. Take for example a KDE user who runs firefox. If he opens a textfile from a secure location, he won't just have to identify himself to firefox to access the location, but again when he opens the file in KWrite because Firefox and KDE don't share the authentication. There is something we need to fix!

Despite the fact both desktops are competing with things like the GNOME Online Desktop and Plasma we should respect each others freedom to innovate, and it shouldn't stop us from looking for ways to share.

Will doing his thing

The above talk really captured the spirit of the conference - sharing and cooperating. It was interesting and I believe there might even be a few concrete results. At the very least there will be more Gnomies at the next Akademy...