It’s been a while since Grilo was released and although Iago’s post announcing it, together with Grilo’s webpage, do a good job describing what Grilo is about, it seems many people out there still do not understand what Grilo is and what it isn’t. Hence, I wrote this non-technical post as an attempt to demystify Grilo.
Grilo means cricket in Galician (CreativeCommons photo by Danforth1)
What Grilo is
Nowadays, a number of online services provide a public API for application developers to retrieve those services’ information. YouTube lets you retrieve videos’ info by browsing or searching; Jamendo lets you retrieve its music and artists’ info in a similar way; and many more offer similar options.
Although many of these services offer a RESTful API, which already makes it easy, it is up to the applications’ developers to write code to access that API, process the results (usually XML) and build their applications’ own structures with the info. An alternative way is, of course, using an already existing library, suitable for the developers’ needs, but whose API might differ from other services’ libraries Grilo exists to solve these issues. Grilo has a number of plugins that retrieve media information from several services. It exposes that information in a consistent API so you don’t have to learn more than one way of getting that media’s info. Although there are more plugins for online services, there are also plugins for UPnP or for the very filesystem.
For the examples given before, searching for media in YouTube or Jamendo would be as easy as calling a method on Grilo, either choosing to search in one, both or all available media sources. The search would result in media objects whose information (metadata keys) can be previously configured. So, this is a very basic definition of what Grilo is: a framework that retrieves content from various services.
What Grilo is not
One thing people often expect from Grilo is for it to play content. Well, Grilo does NOT play media and that’s a planned “misfeature”. Grilo’s main purpose is to retrieve media, or better said, media information, and to do it well. GStreamer is already here to play media and it does a wonderful job at it. Having Grilo to be a media player as well would deviate it from its specialization which would surely make it not suitable for some use cases.
Why should you care
More and more online services are being used in many platforms with applications being developed around them. Grilo eases the development of such applications. For a media player dedicated to play videos from YouTube and Vimeo: Grilo gets you the videos’ URLs, GStreamer plays them and voila, you can focus on other implementation details. Examples of applications that could have they’re job done easier would be Totem, Rhythmbox and Miro.
For Totem and Rhythmbox, Rygel-Grilo (Grilo’s DBUS interface) has already shown (as a proof of concept) how easy it is to provide services as YouTube, SHOUTCast, Jamendo, filesystem’s media, and more, just in a fragment of the code needed to write a dedicated plugin for each of these services. I put also Miro as an example application because it is a video and audio player strongly intimate with the web, Grilo could only make it easy to find these videos. Plus, Grilo’s podcast plugin could also be used to manage Miro’s video channels’ subscriptions.
As a different use case, a desktop like Meego‘s, which integrates, for example, social services in it, could also integrate a way to search media, without the need to use the web browser.
So, summarizing, Grilo fills a gap in the media application development infrastructure; developers that are interested in integrating multimedia content in their applications could get an important benefit from using Grilo to access that content, and that’s why we encourage you to check it out
