![]() |
![]() |
Grilo Reference Manual | ![]() |
---|
Modern media player applications enable users to consume content from various service providers, both local and on-line: Youtube, Jamendo, Flickr, SHOUTCast, UPnP are a few examples of this trend.
Creating powerful applications that are capable of integrating all these services is a time consuming task that requires to invest a lot of effort not only in coding but also in learning about all these services and the particularities of each one.
Unfortunately, applications that already implement support for some of these services do so in a way that is application-specific, disabling the possibility to reuse this code directly in other projects. This means that other applications out there have to do all that work again if they want to integrate the same services.
In this context, the target of Grilo is to provide application developers with a framework where they can work together in the creation of application-independent plugins for managing media content that can be reused directly by applications. This model adds a number of important benefits:
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 applications. 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. If you want to write a media player with support for various 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 have to learn only one API (the framework API) and that would enable application developers to access all these services through the framework plugins.
Application developers will find in Grilo a framework they can use to gain access to a variety of media resources exposed by different services, all that using a single API that abstracts the differences and particularities of each one, easing remarkably the development of modern players.
Platform developers will find in Grilo a framework where they can cooperate in the development of plugins for managing media content from various services.
Grilo is lincesed under the GNU Lesser General Public License (LGPL).