Great Lakes ownCloud developer meetup

I am going to meet up with other North-American ownCloud-ers on October 27th–28th in Ann Arbor, Michigan. The meetup will run in parallel with the main ownCloud developer sprint Fall 2012, which will take place in Berlin. Some of us couldn’t make to Europe, but we decided to meet anyway with a smaller money and travel effort.

Michael Gapczynski (aka MTGap) is taking care of the organization, so refer to his blog for more information. The meetup will be on the University of Michigan’s campus. [Update (October 13, 2012): here is the official page of the meetup.]

You are very welcome to join us! If you are interested, please contact Michael or me. If you live in Toronto or somewhere close-by, I can also offer you a free ride!

ownCloud News app – Alpha release

I am happy to announce the Alpha release of the ownCloud News app, which I developed as a GSoC 2012 project. This is my final GSoC report, so it’s also the time for acknowledgments. Working with the ownCloud (oC) team has been a fantastic experience. The excitement around the ownCloud community is astonishing and people have been extremely kind and helpful with me throughout the last three months. I am very grateful to my mentor Jakob Sack. FOSS projects need people who are much more than just coder, people who are also able to guide other people into the community. Jakob is one of a kind when it comes to this. Many thanks also to Frank Osterfeld (co-mentor of the project), who has been a great source of general “RSS knowledge” and will be very helpful when I will start to work on the API (more details about this later in this and future post). As Jakob pointed out, the project has gained a lot of momentum in the last month. Bernhard Posselt (Raydiation) and Gregor Taetzner (brummbq) joined the project and gave a lot of help with restyling the look of the GUI. I am indebted to them and I hope they will continue to help ownCloud with the same enthusiasm.

The app is basically ready and you can play with it: you can add feeds, folders, remove feeds, folder, view articles, … you know, that kind of things you would do with a feed aggregator :) You can find it in the the master branch of the owncloud/apps repository. Go and clone it! [Update (Aug 25, 2012): notice that ownCloud code has moved to github]

Without further ado, here is how it looks like:

As you may already notice from the screenshot, we decided for an essential look. Some of the usability choices we have made are non-traditional (only one-level folder, no unread item counter), but we hope they will pay off (many thanks to Jan-Christoph Borchardt for those ideas!). Differently from what I stated in the proposal, there is a single view. It will be easier to maintain and we tried to make it intelligent enough so that the user will not feel the need of a different view.

The app also features an OPML importer, which can be found in the Settings panel (click on the cogwheel icon at the bottom of the feed list). If you are curious to see how the feeds that you usually read look like on oC, just open Google Reader, export the OPML of your subscriptions and import them into News.

The plan is to release a final version of the app along with the oC 5 final release (late October/November). Between now and the final release, you are encouraged to test the app and report bugs. Please report an issue only if it’s not listed here yet:

If it is, it means I am already aware of it and working on it. I know, the list is still very long…

The main feature missing in this Alpha release is Sharing. In the final release, the user will be able to share the posts he likes with other oC users and groups, as well as with contacts from his oC address book or just using an email address. This will be based on the new oC5 Share API (see Michael Gapczynski’s blog post.)

The Akregator aficionados who are reading on Planet-KDE will be a bit disappointed to hear that synchronization with their favorite feed reader is not yet functional. Unfortunately, the version of oC News that will be shipped with oC5 will not expose an API. On the other hand, the oC6 version of the app will have an API based on the general oC OCS API, which is being developed in the ocs_api branch of the main owncloud repository. I will talk more about this in a future blog post.

Finally, my app has also been a testbed for an interesting oC feature developed by Jakob Sack. You can read more about this feature here: Background Job. In few words, it works like this: suppose you are taking a two-weeks vacation from your nerdy life of checking your feed reader every day, but you don’t want to miss any of the posts that are published at the same time. Then your oC server will do the job of collecting the unread posts and store them while you are playing matkot on the beach. This is cool, isn’t it? Ok, do I sound like I am craving for a vacation? I am actually going to take one in few hours :P See you in September!

ownCloud feed aggregator – the M part

Hello KDE/ownCloud fellows!

After one month of GSoCoding (and quantum information research), I am finally back to blogging. Let me be honest from the beginning: there will be no screenshots in this post :( This is because the first part of my project was entirely devoted to the most hidden layer of the aggregator app: the model part, the M of MVC (Model-View-Controller) — the pattern used in the design of ownCloud applications. In this post I would like to explain the details of my implementation and share some of the things I learned during the first weeks of my GSoC.

The most important entities in a feed reader application are collections and items. As you can imagine, a collection is a set of items. The collections are organized in a tree, whose nodes are the folders and whose leaves are the feeds. In my implementation, folders and feeds are objects of the classes OC_News_Folder and OC_News_Feed, respectively. These classes extend the class OC_News_Collection. “Class”, “object”, “extend”? Yes, I am trying to design this app using object-oriented programming principles. I know, PHP is not the most comfortable language when you want to do OOP, but I still believe that this approach will make the code better organized. There are many aspects of PHP5 I could bitch about here (lack of a real overloading, for example), but I will rather refer you to this amazing post by Eevee. Anyway, ownCloud is written in PHP for very good reasons, so lamenting doesn’t really matter. I still believe it is possible to write nice OO code in PHP. <ad>A book that I found very helpful with regards to this is PHP Objects, Patterns and Practice by Matt Zandstra.</ad>.

The actual parsing of the feeds is handled by the SimplePie library (many thanks to its developer!). The interface between the SimplePie layer and the modeling classes is provided by some static methods of the class OC_News_Utils. The aim is to make the SimplePie layer very independent from the rest, so that in future it will be easy to eventually replace it with some other RSS/Atom parsing library.

Another layer that needed to be decoupled from the layer of the domain objects is the persistency layer (in our case, the same as the database layer). An elegant solution for this is provided by the Data Mapper pattern. In a few words, a mapper acts as an intermediary between the memory and the database. It provides CRUD methods that output, or take as parameters, objects lying in the memory and map them to rows of the database tables. In my implementation, for each class X describing a domain object, there is a class XMapper for the corresponding mapper. As an example, the class OC_News_FeedMapper contains the method save which takes an instance of the class OC_News_Feed and write the corresponding data in a row of the feed table in the database.

This was a brief summary of the design choices I have taken so far in my GSoC project. If you want to know more, you are invited to grab the code from the owncloud/apps repository – branch newsapp. The classes I described above are all in the folder news/lib. Since the official release of ownCloud 4, I am using the branch stable4 of the main ownCloud repository as development environment (note that this changed since my last post, where I was suggesting to use the master branch).

The model layer is not perfect yet: some methods are missing, others need to be clean, not everything is very efficient, etc. Moreover, I haven’t tested it thoroughly. The main ideas are there, though. I’ve already started to code the interface part and I will make further improvements to the M part along the way.

Feel free to comment and stay tuned for a post on the V part!

Announcement: In about a month, I will start to implement the API. If you are the maintainer of a feed reader, please contact me if you are interested in syncing your client with the ownCloud aggregator. I would like to receive suggestions from you on the API before I start to code it.

A feed aggregator for ownCloud – week 1

Alternative title of the post: Yet another “hey, my proposal got accepted to GSoC!” post.

In the next three months I am going to develop a feed aggregator for ownCloud as a Google Summer of Code 2012 (GSoC) project under KDE. The mentors of this project are Frank Osterfeld and Jakob Sack. As you might remember from my previous posts (1 and 2), this belongs to a wider project that aims at synchronizing KDE Akregator on the cloud. If you are interested in more details, you can read my full proposal here.
This is how the web interface of the aggregator is going to look like (in two different views):


There are big changes happening in these days for what concerns the way ownCloud handles apps. Consequences of this are:

  • the apps folder can now live outside the main owncloud folder;
  • core and secondary apps are going to be moved to a single repository.

If you have already installed ownCloud and you want to follow the development of my app, then you need to clone the following repository:

owncloud/apps.git branch:newsapp (

A stub of the feed reader app is already in the subfolder news (‘News’ is also going to be the user-friendly name of the app, as well as the owncloud app id – feel free to comment if you like it or not).
Unfortunately it is not possible to specify multiple app folders yet. If you want to both use ownCloud core apps (from the owncloud/owncloud.git repo) and check the development of my app at the same time, I recommend the following setup:

  1. install ownCloud in /your_web_server_root/owncloud
  2. clone the above-mentioned repository in the folder /your_web_server_root/apps (remember: my app is in the working branch newsapp
  3. create a symbolic link pointing to the folder /your_web_server_root/apps/news from the /your_web_server_root/owncloud/apps folder.

Things will become cleaner once the transition to the new app system will be complete. Stay tuned!

Want to hack on Akregator? Here is how to set up the environment.

Hello KDE community!

First I want to thank everyone who showed interest for my last post and for the “Akregator reborn” project in general.

The good news of today is that Christophe Giboudeaux (krop) did an amazing job in the last week with moving all the stuff that concerns Akregator in a new branch of kdepim. In the following, I will explain more in details what happened. I will also give some tips for the non-experts on how to set up an environment to comfortably hack on Akregator.

As you might remember from my previous post, the plan is porting Akregator to the Akonadi framework. Until the last week, approaching Akregator’s code for someone who hadn’t followed its development in the last years was something not trivial. Things changed a bit and, as a first step, I am going to explain which repositories you should refer to if you want to hack on Akregator. Before the repositories restyling of the last week, the situation was quite confusing. The Akonadi-based version of Akregator, along with the krss library, used to be in the branch work/akonadi_port of kdepim, the new (well, not that new anymore…) resource krsslocal was in my personal scratch repository and the non-Akonadified Akregator was being developed in kdepim master. Everything is now in a new branch of kdepim named akregator_port. In particular, in that branch you will now find two versions of Akregators:

  1. akregator, based on Metakit;
  2. akregator2, based on Akonadi.

The most immediate goal is making akregator2 complete and stable. Moreover, since the development of akregator (the Metakit one) went ahead during the last years, another goal is merging all the bug fixes and the polishing that were done in it to akregator2. Probably many of them don’t apply to the new code, but some of them might (UI fixes for examples).

Just to recap, in case you want to hack on Akregator, you need to build:

  • kdelibs KDE/4.8;
  • akonadi >= 1.7;
  • kdepimlibs from master branch;
  • kdepim from akregator_port branch.

WARNING: akregator2 in kdepim akregator_port is unstable and not suitable for daily use yet. Please use it only for testing and development purposes.

When things will become more stable, their placement will become more logical, possibly as follows: akregator2 will replace akregator in the master branch of kdepim, krss will be moved to kdepimlibs and all the RSS-related akonadi resources, such as krsslocal, will go to kdepim-runtime.

Here are some tips for beginners on how to build the above-mentioned libraries and programs. If you are not a beginner, you can skip to the end of the post and start hacking!

The weekend in which I updated my setup for the new environment on my machine turned out to be quite frustrating. The initial idea was reporting each step that led to the setup on this post, but once I had managed to make it working, I started to think: “mmm, why should I waste my time writing up yet another how-to for building a piece of KDE? Probably what I did was not that difficult either…”. What convinced me to write the following tips is Leslie Hawthorn’s amazing essay from “Open Advice”, which reminded me that in fact this is the perfect moment for sharing basic knowledge, this is time when I know “…Everything They’ve Forgotten”.

The process of building KDE strongly depends on the Linux distribution you are using. Of course, the more outdated the packages are, the harder it will be to make things working. This disclaimer is due to the fact that I am using Debian stable and the packages over here are not the most recent ones…
An advice: mixing stable and testing packages of a distribution usually doesn’t end up very well. I would rather recommend to install from the sources those packages that are not up-to-date in your distro repositories.
If it’s the first time you are building a piece of KDE, you may want to read a bit of official documentation. In particular, the following is mandatory reading that you must not skip:

In my first attempt, I tried to use kdesrc-build to build all the modules, but I didn’t succeed (thanks yottabit and PovAddict for the help with this try). If you manage to make it working, please let me know.

Edited: Frank (fosterfeld – maintainer of Akregator) is using kderc-build to build everything in the above setup, except kdepim-runtime and kdepim. You can try to make his script working on your machine.

I switched to a more manual procedure and things went pretty smooth. I still found extremely useful those scripts that you can download on Don’t forget to customize them according to your preferences. For instance, I built my own Qt, so I uncommented and modified the line

export QTDIR=/usr/local/Trolltech/Qt-4.8.0

in .build-config.

The following is the minimum set of packages that you need to install (notice that they are listed in the same order as the one in which you need to build them):

Qt (4.8.0 suggested) > DBusMenuQt > kde-support (akonadi, attica, soprano, strigi, shared-desktop-ontologies) > kdelibs KDE/4.8 > kdepimlibs master > kdepim akregator_branch

The libdbusmenu-qt from the KDE repository was not working on my environment, so I used the one from the official repository. Notice that the gitorious version of libdbusmenu is no longer maintained and you need to use the Launchpad repository (again, only if it’s not already included in your distribution). The following command will clone libdbusmenu-qt from the Launchpad repository:

bzr branch lp:libdbusmenu-qt

Another tip: the option -b <name_of_the_branch> of the git clone command clones and checkouts the specified branch. For example,

git clone -b akregator_port kde:kdepim

will clone and checkout our beloved repo :).
Lastly, when you configure kdepim, run cmake with the option -DKDEPIM_BUILD_MOBILE=FALSE.

If you master KDE development and you haven’t skipped the last paragraph, feel free to comment with corrections and improvements about the above tips.

If you have questions or comment, you can find me (zimba12) in the #akregator and #kontact channels on Freenode, you are welcome to send me an email or just leave a comment below.

The end of this post is dedicated to another exciting news from the last week: Dan Vrátil (progdan, dvratil) wrote KDE Google Reader, a client for reading Google Reader feeds on KDE. Even though it’s just a preview and Dan wrote it “purely out of interest”, it’s still very nice to see a lot of fuss around the RSS/KDE matter. Perhaps someday he will write a GReader Akonadi resource that will integrate with the future Akregator.


Let’s make Akregator hot again!

Hello KDE fellas!

After a very busy university term, I have finally got myself to write this post about the status of reading RSS/Atom feeds on KDE. Consider this post as if it was written in September 2011, things have been pretty much frozen since then.

The aim of it is:

  • updating the KDE community on what is new with news feeds reading in KDE;
  • “refactoring” ideas in my mind after a semester of slacking off;
  • encouraging people to help making the “feeds reading experience” on KDE cool again! (YES, I AM asking you to join this project)

Akregator (news feed reader of the Kontact suite) was introduced along with KDE 3.4 in 2005 and aficionados of the KDE platform are still using it. However, many other users switched to more convenient web platforms such us Bloglines earlier on, or Google Reader (GReader) lately. Look at these statistics on the GReader devs blog. Ok, it’s not clear what the y-axis in those graphs represents, but still… Unfortunately, Akregator has also been struggling with attracting new users. See this survey from and you will have a picture of what many geeks choose as they favorite news feed reader. Alas, it’s hard to find a single comment where the Big-G aggregator is not mentioned :( What makes so many readers to favor the Google aggregator? Well, as usual in the case of Google products, it works fairly well and it has got almost all the features that most users want. In my opinion, there is more, though. The most important feature of GReader is that it’s out there on the web and, no matter where you are, you just need a browser and a Google account to access it. What is wrong with using Google Reader then? First of all, you also need an internet connection to access it and you know, that’s not really everywhere (Notice that since May 2010, the offline feature of Google Reader is no longer available). Second, in terms of comfort, nothing beats a KDE application, with its perfect integration with your desktop, notification system, ability to use quick search features, and so on. Third, if you care about your privacy, the new Google’s privacy policy is definitely not something that can make you happy.

This leads us to the encouragement that titles this post: let’s make Akregator sexy again and let’s switch back to it! An idea for doing this came up in the last summer, when I was looking for a Season Of KDE project. I was chatting with Jakob Sack (jakobsack) and Robin Appelman (icewind) on the #owncloud channel and they mentioned that a feed reader was one of the most important among the applications missing in ownCloud. If you don’t know what ownCloud is, you should absolutely check it out (! Jakob’s and Robin’s idea was not just to create an online feed reader, but something way cooler: bringing Akregator to the cloud. Immediately after this idea came up, I checked it with Frank Osterfeld, the Akregator maintainer (Frank from now on). Since the very first conversation with him, it became clear that there was a fundamental preliminary step to take before bringing Akregator to the cloud. This was a fully working port of Akregator to Akonadi.

Started few years ago, the creation of the Akonadi framework gave fresh nourishment to the development of applications that manage personal information on KDE, i.e., KDEPIM applications. Many components of Kontact, the personal information manager of KDE, greatly benefited of the port to Akonadi with new interest and new features coming to the platform. Unfortunately, one of the components that was left out from this trend was Akregator. The basic reason for this was that Akregator has always had basically only one committed maintainer, Frank (kudos to him!), and not many other developers involved. A partially working port of Akregator to Akonadi eventually happened in 2008-2009, when Frank was joined by Dmitry Ivanov, a GSoC student at that time. You can read more about the amazing job that Dmitry and Frank did in that period in Frank’s post dated July 2009 and Dmitry’s post dated November 2011.

What happened since then? Not much. No earth-shattering changes happened to the code and the port to Akonadi never made it to the master branch of KDE. Again, the reasons are: basically no developers involved and the code that had become very complex, mainly because of two architectural choices. First choice was the decision to use tagging instead of a simple folders tree structure. Second, the choice to write a common resource for all the RSS services and just a sub-instance of it for each individual service (Newsgator, GReader, local). Dmitry’s resource is called krss and it’s in kdepim, branch work/akonadi-ports.

The news is that during SoK 2011, under Frank’s mentorship, I wrote a new Akonadi RSS local resource. It imports information about the feeds from an OPML file, loads the items and store them in Akonadi. You can flag the items as read/unread/important, and organize them in folders. We used many pieces of Dmitry’s code, including the serializer and all the classes that model the basic objects such as feeds or items. We rewrote the basic methods that define the resource from scratch. The code became simpler, although some features are missing in the new resource. It’s also less general, since you can’t extend it easily to any application other then the OPML storage. It works, though, and you can see it in action in the following (mandatory) screenshot :).

Screenshot of krsslocal on Akonadi Console
krsslocal on Akonadi Console

You can find the source code in the following repository:

If you want to suggest features, report bugs, or just comment about the resource, feel free to buzz me (zimba12) on Freenode (I am very often in #owncloud and #akregator).

Other encouraging news: Frank wrote a new migrator for the old data (it’s in kde:clones/kdepim-runtime/osterfeld/akregator-migrator) and he fixed some bugs on the Akonadi port of Akregator (it’s in kdepim, branch work/akonadi-ports) while testing it against the new resource.

Finally I believe there can be new excitement around Akregator!

Screenshot of krsslocal on Akregator
krsslocal on Akregator

If you also got excited and want to know more, you can check out my wiki where I take notes about the entire project at the following link: I use it as scratch paper so the information won’t be much coherent. In case it doesn’t make sense, feel free to ask me questions on chat.

Once again, this IS a call for joining the project and don’t forget the KDE Philosophy: When making a suggestion, change “we should..” to “I will..”.

In the part 2 of this post (stay tuned on planet-kde for it!), I will be talking more about the ownCloud feed reader application on which I am working right now and how this will be integrated to Akregator+Akonadi in the future.


Programming Pumpkin Fries

Many things happened from the last post. The most important, October has arrived! The first consequence of this exciting coming of a new season is the wonderful metamorphosis of the shelves of our beloved farmer’s markets. Without any doubt, squash are the heroes of this month: spaghetti squash, butternut squash, zucchini, acorn squash and, above all, pumpkins, the indisputable leaders of this terrifically tasty team.
In this post we will talk about pumpkin fries. The idea is simple: you cut and fry a pumpkin. Much more difficult than potato fries, though, if you want them to be crispy on the outside and soft on the inside. “Here we are, again! This is just another cooking blog!”

It’s not. The actual reason why we care about pumpkin fries is because they triggered the interesting following meta-question on a Theoretical Computer Science (TCS) forum:

Is asking for a cooking recipe “a question about algorithms”?

The forum is a collaboratively edited Q&A website for TCS people and the above question provocatively relates cooking and computer science. In particular it subsumes a more fundamental question, which is also the raison d’être of this blog:

Is a recipe an algorithm?

Since primary school, when we are for the first time introduced to the concept of an algorithm, we are suggested to think of it as something similar to a recipe. The discerning reader might have already noticed that the title of this blog is a line from The Art of Computer Programming (TAoCP) by Donald Knuth. In fact, in the introduction to the first volume of TAoCP, prof. Knuth sanctions the comparison between algorithms and recipes, although he underlines that a recipe “lacks definiteness”. His book and in general the science of programming computers are based on the analysis and the theory of algorithms, that is, studying the ability and the behavior of machines in solving problems.

If we accept the recipe-algorithm analogy, even by properly relaxing the definiteness condition, many questions arise. Can we apply some of the results from seventy years of research in programming computers to the art of programming food? Is there a model of computation, among the ones we have studied so far, that well describes the process of making food? Or do we need new models?
Foodies, engineers, geeks, bloggers and 3-stars Michelin chefs coined terms like “food science”, or “molecular gastronomy” and a cooking revolution is in front of our eyes. It is paradoxical, though, that the science of algorithms is not involved in this process of scientificizing (maybe also “deromanticizing”) the craft of creating good meals. Let us suppose one day we will end up building machines that will replace chefs or ourselves in restaurants and home kitchens. Obviously, a chef robot is going to have sophisticated motors and sensors, but how smart will its brain need to be? Is cooking all about physics, chemistry and biology or it is computer science too?

In the next posts we will try to go deeper into the questions we posed here and we hope the readers will animate the discussion with insightful comments.

Pilot – Beetroots

Grigori Perelman is a Russian mathematician, who has recently proved the Poincaré conjecture, one of the Millennium Prize Problems. Awarded of a $1 million prize by the Clay Mathematics Institute, he has refused to accept it. Grigori lives only with his mother and sister in very humble conditions, in a small flat in St Petersburg. Among all the stories that started the legend of this reclusive genius,  the most interesting for AftK (Algorithms for the Kitchen, i.e., this blog) is the one that concerns his diet. According to this story (sorry reader, no reference for the legends), Dr. Perelman’s diet consist only of beets and black cabbages. We firmly believe that whoever wants to approach the P vs. NP problem should stop hating these amazing vegetables.

The summer is over and the farmers’ markets are getting full to overflowing of sweet and juicy beets. If the above story convinced you and you are going to put your hands on a big problem, then it is the right time to become a lover of this root. You don’t know what to do with them? Don’t panic! Visit this entry of the BBC h2g2 to know more about beets and start with a relatively easy recipe from the Canadian Prairies.

Well, this looks just like another cooking blog! And you didn’t write the recipe by yourself! You didn’t even show pictures of the result! Fair, fair… indeed this post shows how this blog is not going to look like. We will try to keep our writing as distant as possible from a traditional cookbook and instead close to an Algorithms textbook. We will not merely present recipes, we will show how to design them!

The authors of this blog solicit help in finding any mistakes that we will make and in sending corrections, although we can’t guarantee to reward the alert reader of any amount of money. Also, we will never bet on the accuracy of a recipe.


  1. Add the RSS feed of this blog to your favorite aggregator.

Update: While I was writing this post, I happened to see a flyer advertising the book tour of Cooking For Geeks by Jeff Potter. I didn’t know about the existence of this book and I ordered a copy immediately. As soon as I will get it and have the chance to read it, I will post a review.