The idea is to decouple providers and consumers, this way one does not have to worry about the language they are written in and providers don’t have to be loaded in the consumer’s address space, instead they are communicated through D-Bus.

So, what could be Grilo’s role in this context? As you know, Grilo is a pluggable framework that provides a single, high-level API to consume contents from various sources (Youtube, Jamendo, SHOUTcast, etc) which are implemented as plugins for the framework. As such, the role of Grilo would be that of a content provider. Juan has been working on a daemon that would use Grilo to get access to all the content exposed by the framework and expose it over D-Bus according to Rygel’s MediaServer spec. This will enable Rygel (or any other application), to get access to all this content over D-Bus.

As of today, I think only Rygel has implemented the consumer side of this API, but the idea is that in the future other applications like Totem or Rhythmbox would have plugins to consume it too. Also, since Rygel is a UPnP server, and it is feeding on Grilo through this D-Bus interface, it is also exposing Grilo’s contents to the UPnP world, so any UPnP client should be able to access these contents over UPnP thanks to Rygel. Totem for example, has a UPnP plugin already, and because of that it can consume the contents from Grilo through Rygel even when it does not implement the consumer API of the MediaServer spec.

If you are interested in more details check Juan’s post here. There you will also find a screencast showcasing a Grilo-powered daemon that’s exposing content from various of its plugins over D-Bus, then Rygel feeding on that and exposing them over UPnP, and finally Totem consuming all the content though its UPnP plugin. Of course, you may ask why wouldn’t Totem feed on D-Bus directly, well just because it has the UPnP plugin already and not the D-Bus one, but it will come .

Talking about that, another thing that Bastien proposed and on which we will be working too, is a set of helper libraries to ease development of content producers and consumers. On the producer side (backends) the idea would be to hide all the D-Bus stuff and provide a clean, easy to use interface for exposing content to the bus (for those not wanting to deal with D-Bus directly), and on the consumer side (frontends), we could do the same and maybe add some extra bonus stuff, like widgets to manipulate available sources and the like.

Browsing and playing videos from Youtube

Browseable sources

Searching images on flickr

Searching Guadec videos on Youtube

Browsing content from Jamendo

I have also recorded an ogv video showing the plugin at work in more detail, you can check it out here.

Also, I uploaded the code to gitorious if you feel curious about it. If you want to build the plugin from the sources check the HACKING file on the repository. Also, I suggest you build Grilo from the sources as well or wait for the release 0.1.3 which should be coming out later today.

Now to the more interesting part, the good thing about Grilo is not just the plugins, it is the fact that you can interact with them with a common API. As a matter of a fact, I could now add more plugins to Grilo and those would show up in Totem without having to code anything extra, not a single line on Totem or its Grilo plugin, it would just work: you would be able to browse the new plugins if they are browseable in the Browse view and/or you would be able to search them if they are searchable in the Search view, etc.

The plugin is not really finished, it can still use some extra work, particularly in these areas:

• Localization support.
• Proper user interface definition with GtkBuilder.
• Settings persistence with GConf.
• Usability tweaks
• Review memory management, fix memory leaks, etc
• More testing and general debugging.

but all in all, it is good enough already for others to try and give feedback, so if you have any, please drop me a comment!

That’s all for now, I am looking forward to seeing this on the upstream Totem at some point in the future, so if some Totem developer is reading this, please let me know how you feel about that.

• Juan is packaging Grilo, check details here.
• We have bindings for Vala thanks to Víctor Jáquez.
• Grilo 0.1.2 is released, check this post for details.
• We have a plugin ranking system now. This is used when you request Grilo to resolve metadata for a particular media object and there are various plugins capable of doing so (imaging for example that you have two plugins for resolving the album art or the lyrics, etc).
• We have set up a PPA for Grilo on Launchpad, details here.
• I am working on a Totem plugin, so far I got a first prototype working and I can use Grilo sources from Totem enabling me to browse and play content from all the Grilo plugins. Now I need to focus on adding a few more features and configuration options.

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…

• The event itself was nice and well organized, probably one of the best events of this kind I have attended in the last years. Thumbs up for those who worked on making it possible. Maybe the N800 and N770 rooms were too small, but other than that it was great.
• Thanks to Nokia for letting us try the N900 before its launch date. So far I am very happy with the experience and I think it represents an impressive step forward from the N810. I’ll make sure to give you my feedback here and also in bugzilla.

I also had a presentation about MAFW there which I hope helped some people with getting started on writing plugins for MAFW. I have to admit that I had thought of giving a very different type of presentation, more based on actual source code than slides, but anyway… I just provided insight on some key ideas around MAFW and its plugins, and then I left the source code examples (which you can grab from previous post) for those willing to get their hands dirty with the details.

The session was nice, I got some interesting questions/feedback during and after the session and I hope all that feedback translates into a better MAFW at some point in the future. Some highlights (in no particular order):

• We need the Python bindings. Andrea Grandi briefed people about this on his lightning talk. There are some parts of MAFW that are not using GObject right now and that is a source of trouble for the PyMaemo team, they could use some help from people with C and/or Python experience to give the bindings a boost, so if you are reading this and think you can help them I am sure they will be pleased to know about you . Also, I wonder if patching MAFW to be fully GObject based is still an option in Fremantle…
• Canola wants to be more integrated with Fremantle and for that they are considering using tools like Tracker and MAFW. They could get rid of the indexer tool (Tracker would handle that) and they could get access to local content, upnp media bookmarks and radio directories for free using MAFW, they could even use MAFW’s GStreamer renderer. Also, if we get new plugins for MAFW in the future these would be available for Canola too, etc.
• Talking about Canola, I was not able to attend their session because it was scheduled in parallel with mine about MAFW (this is probably my only complaint about the event), but Iván Frade (Tracker) did a good job representing MAFW there, so thanks Iván
• Since we are lacking the Python bindings, someone suggested that we should document our D-Bus APIs. That was indeed a good point, although I am not sure if all the APIs can be used directly that easily (there is some data serialization associated to the APIs that gather metadata information).
• It was also interesting to see how people would like to have a bit more of control/integration with the Media Player. That’s out of the scope of MAFW itself, but I think it is an interesting point for Nokia. I guess the idea here would be to allow third party developers to write plugins for the Media Player itself, that would enable them to modify/extend the way the Media Player works. One example of this would be a ratings plugin that would show a dialog to rate a movie when it has finished (just an example). I think this could be somehow achieved using a separate MAFW-based application, but it would be easier and nicer if the Media Player itself provides some interface for developers to do things like this.

I also had other interesting corridor chats with people about how one would write a Youtube source plugin for MAFW, how to integrate a Mozilla Flash renderer with Media Player, enabling applications to access additional metadata using Internet services, etc.

So overall I had a great time there and I think it was well worth my time. I am already looking forward to the next edition

Unfortunately, 20 minutes is not a lot of time to explain what MAFW is about and go into the details of the plugins’ source code. So here is the deal, do you prefer to see me showing you the code and explaining how it works, or do you prefer slides covering the basic ideas and leave the source code off the presentation?

In any case, you can get the pluigins’ source code here:

MAFW Filesystem source plugin

MAFW Simple renderer plugin

UPDATE: You can now also check out the slides here:

Writing plugins for MAFW (slides)

• 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.

The talk is scheduled on Wednesday 8th July, for details on MAFW and the contents of the talk you can take a look here.