Category: Uncategorized

After working for quite some time in MAFW for Maemo I thought it was about time we exported some of the ideas to other platforms, including the desktop, of course. For those who haven’t heard of MAFW yet, you can get a good description of it in the abstract of the talk I gave at GUADEC last year.

MAFW takes care of quite a few things related to high level multimedia development, but there is one in particular I find specially interesting, which is source abstraction. Basically, MAFW defines a set of interfaces for accessing media content providers (a.k.a. Youtube, UPnP servers, local media, radio streams, podcasts, etc). in a generic way (one API to rule them all), easing a lot the effort required on the application side to write modern media players that integrate many of these services.

MAFW was a step forward in this regard, but probably too tied to Maemo in general and to its Fremantle iteration and the N900 in particular. I think the ideas behind MAFW about media browsing are totally valid outside Maemo, however I find its implementation and design packed with Maemo specific (or even N900 specific) choices. I guess this is ok for Nokia since Maemo is its major priority when developing software, but for those willing to export these ideas to other contexts, like me, it is not good enough. And this is is why we have created Grilo.

Grilo is a framework focused on making media discovery and browsing easy for application developers which has been developed following some of the good ideas behind MAFW but with a broader target in mind and adding some extra interesting features as well. In few words, Grilo provides:

• A single, high-level API that abstracts the differences among various media content providers, allowing application developers to integrate content from various services and sources easily.
• A collection of plugins for accessing various media providers. Developers can share efforts and code by writing plugins for the framework that are application agnostic.
• A flexible API that allows plugin developers to write plugins of various kinds.

At the moment, even though we are still starting the work, we have a bunch of plugins already available that provide support for various kinds of services:

• Youtube
• Jamendo
• Flickr
• Podcasts
• UPnP

We also have a simple GTK+ test user interface that allows users to browse, search and query these plugins for available media, for those who want to get a grasp on how the framework can be used from an application. We also have a Last.FM album art plugin too.

Grilo is LGPL and its source code is available on Gitorious. We welcome interested users and developers to check it out and provide feedback, patches or new plugins. We are still in the early stages of the framework definition and we are looking forward to incorporate new ideas into it.

The advantages of having a framework like Grilo are easy to spot:

• Less work on the application side. All the plugin development happens in the framework and application developers can focus on making good user interfaces. It is the same with GStreamer if you think about it, application developers do not have to write decoders to playback content any more, they get the decoders from GStreamer (the framework) and that eases a lot application development. Well, this is the same idea, but applied to media browsing and discovery instead of media playback.
• Code reuse. There are many media player applications allowing users to access contents from various services. This is nice, but all this is done at the application level, which usually means that all that code cannot be directly reused in other projects. Because of that there are developers writing application specific plugins for all these services in various applications (Totem, Rhythmbox, Amarok, etc), replicating code that cannot be reused directly in other projects. If the plugins were developed on the framework side, all these developers could share efforts and write support for these services only once in the framework, making them available for all the applications using the framework for free. Every one wins.
• Quick learning curve. Think about it, if you want to write a media player with support for various different media content providers, you would have to learn how to deal with each one of them independently: want to add Youtube videos? go and learn about Youtube data API, want to add music from Jamendo? go and learn about how Jamendo allows you to do that, want to provide access to your local media? Go and learn how Tracker APIs work for example, want to access UPnP servers? then go and learn about using GUPnP, and so forth… this is a lot to learn, and even more code to implement. The framework approach would ease all this, one would only have to learn only one API (the framework API) and that would enable application developers to access all these services through the framework plugins. These plugins act as adpaters for those into design patterns.

I guess this post is getting long enough for now, so I’ll stop here and write more about Grilo some other day…

Today I attended a bunch of interesting talks. My highlights:

• Toward GStreamer 1.0 by Jan Schmidt. One of the targets in the road to 1.0 is to provide more base classes, hopefully I’l manage to help with this.
• Profiling and Optimizing D-Bus APIs by Will Thompson. We hit some of the problems he mentioned while working on MAFW.

Thanks to Frederic Peters, who’s kindly worked on providing a new design that’s more integrated with the Gnome Website look and feel, and Alejando Piñeiro, who’s been working on actually making it work with our Builbot installation.

You can check it out here. Hope you like it!

As some of you may already know we have been postponing for some time the addition of new slaves to build.gnome.org. The reason for this was that in order to allow other slaves to connect to our master we had to open a large range of ports in the firewall, fact that worried some people maintaining the server. So, I and my mate API invested some time (more than we would have liked to) trying to find a solution based on a single public port. Unfortunately, our lack of experience with the Twisted framework was a constant pain and made it a bit difficult to move forward. In the end, we managed to implement a solution which worked fine… for a while, until the TWisted beast bit us hard, yet again, with a random, low-level, indecipherable error…

So, at that moment we had to choose: either we continue working on that, maybe delaying work on the build brigade for some more weeks or months, or we find a temporary workaround to keep things moving forward. Of course, we chose to keep things moving forward ;), so we moved the master back to Igalia with the help of Olav Vitters and enabled two slaves: the one we had in the old build.gnome.org and a new one running at Igalia. You can see the results in the gnome-buildbot web page. Of course, this means that now we can finally accept new slaves, so let us know at the build-brigade mailing list or IRC channel if you want to do so! We will be glad to guide and help you in the process.

Meanwhile, we will still try to find a solution to the ports issue, but now with a new approach, thanks to John Carr for working on this matter!

PD: Sorry to those who had offered slaves but have had to wait so long for us to get this done.

I’ve checking out the gnome mobile moduleset created by Ross Burton some days ago. My idea is to setup a gnome-mobile-buildbot that provides continuous integration of gnome-mobile software stack in several architectures.

First attempt (Debian, i686) quite successful:

The Gnome Buildbot has been showing many modules failing on update stage for some time. This had to do with some changes in Jhbuild to support Mercurial repositories (back in May) and, specially, the inclusion of mercurial repositories in the modulesets.

The reason for this to fail in the Gnome Buildbot was that we were not using an up-to-date Jhbuild version and a simple update would not do the trick here because we were using a slightly patched Jhbuild version. You might wonder why we did not push our patches into jhbuild in the first place, but the truth is that we did it since the very beginning, however, there was still one of them pending to be applied because it needed some tweaks prior to go upstream and these fixes were postponed for too long… (my fault).

When the modulesets were updated to actually include mercurial repositories, our jhbuild version raised the problem because it did not know anything about this repository type. Nothing better than actually see a problem to start working on solving it, suddenly fixing that pending patch became my most important ToDo item :), after some days of work and the valuable help of Frederic Peters, we managed to get a functional, corrected and up-to-date patch against Jhbuild trunk, so finally the Gnome Buildbot is working using a non-patched version of Jhbuild.

For the future, now that we run a non patched version of Jhbuild, and taking into account that jhbuild is a key component of the Gnome Buildbot, we should consider a regular update mechanism that keeps our build environment up-to-date.

BTW, thanks to Frederic for helping us with this! (and also with the other patches we merged in Jhbuild), you have definitely made our life much easier :).

For those of you interested in the slides of my talk about the Gnome Build Brigade at Guadec

Answering to Olav post about my plans for the gnome buildbot: the more slaves, the better :). However, it is obvious that I cannot review all build errors on all modules for all the slaves, besides it makes not much sense… for me, the good way to go here would be that project maintainers and core developers (at least) subscribe to the modules they are experts on and whenever they receive notification that any of these projects fail to build, drop by the buildbot and check what’s going on with it. I’m sure they’ll know better and will realize sooner in most cases what’s going on there, so they can fix the problem in the repository if needed or give feedback to us so we can fix the build for that module (for example using appropriate build flags, installing missing dependencies, etc.).

Btw, I removed the test coverage stuff to build scrollkeeper successfully at least once, so modules failing to build due to its dependency on this module can build. Unfortunately, I see that gnome-doc-utils failing to build is also causing a lot of build problems in other modules. Is there anyone who can help us out to fix this build error?:

xsltproc -o "C/db2html-bibliography.xml"
--stringparam basename "db2html-bibliography"
--stringparam xsl_file "/usr/local/buildslave/gnome/work/src/gnome-doc-utils/doc/xslt/../../xslt/docbook/html/db2html-bibliography.xsl"
"./xsldoc-docbook.xsl" "C/db2html-bibliography.xsldoc"
db2html-bibliography: No documentation for template mode l10n.format.mode

See complete Log here.