GUADEC 2012. Grilo BoF Minutes

The topic of the BoF is how to spread the adoption of Grilo.

Improvements for application developers

The question is how to improve our bindings so Grilo can be used with different programming languages. We agree that probably we need to check our API to make it more bindable friendly.

During the talk Lucas Beeler, from Yorba Foundation, showed an interest in the Vala bindings. He is one of the main contributors of Shotwell, which is written in Vala, and he would like to use Grilo to upload content to different services.

Action Point: Lucas will help in checking the quality of our Vala bindings, and fix them if needed. Also, as he is experience with the uploading-content use case, will check our API for uploading content and propose improvements, as when we designed it we did not have good use cases.

Improvements for plugin developers

It is clear that our current approach of writing plugins in C has its drawbacks:

Not everybody is experienced in C language
Written in C takes more time than using a higher level language, depending of course on the experience of the developer and how well the language suits for the kind of plugin to implement.
At last, but not least, our plugins needs to cope with all the asynchronous burden to make the applications responsive and avoid freezes in the UI.

One of the steps we started to help on above problems is a XML-based plugin, which allows to define sources with XML. Though it is a good step, we can go further:

Developers should be able to use the language of their own choice
The approach to implement the plugin should not be an alien. That is, when developers see what they must implement to have a plugin should feel very natural to the language.
Developers should not fight with all the asynchronous stuff neither other boilerplate code.

Bastien Nocera proposed in the mailing list using Lua to implement plugins. So we are going to address the problem using Lua as the target language: it is a scripting language easy to learn, suitable for the sort of things we need to deal when implementing a plugin, and with few dependencies and small fingerprint that makes it easier to integrate in C.

The approach will consist on defining an API that developers must implement in Lua to have a plugin, and a wrapper layer to adapt the plugin to Grilo. This layer would provide utility functions to plugin, and handle all the asynchronous stuff we mentioned before.

Action Point: Juan A. Suárez will finish the XML-based source, and start with the Lua support

Support for music/video stores

This point makes reference to those services that require to do a payment in any moment. We have identified 3 cases:

You do not need to pay for listening/watching content, but at any moment you can pay a contribution. This is the case of Magnatune. The approach we can use to solve this case is having a "payment-url" key that can be exposed to the user, so they can follow it opening a browser that takes them to the page to do the payment.
You need to be subscribed in order to listen/watch content. This could be the case of Spotify (though it also has the option of advertisement-based subscription). In this case we assume that user has subscribed before by other means, like using a specific application or just a web browser. The plugin would check if the user is allowed to access the content (subscription is valid) and if so, expose it.
You can browse through the content, but before listening/watching it, you need to rent it. This could be the case of online video clubs. It is not clear how to solve this case, as we do not know how Grilo would know the content has been rented. So we will not support this case for now.

Plugins needed

It was mentioned that having a plugin for Imgur would be a good idea. In general, any plugin is welcomed, and there are different requests in bugzilla.

Introspectable configuration in plugins

Some of the plugins supports or require to set up some options. But these options are not introspectable in run-time: application developers need to check the plugin documentation to see what options are supported. This has the drawback that it is not enough with just installing a plugin to use it. What it would be good is to have API to discover those options and ask user for values for them.

As example we can look at XBMC: when a plugin is installed, it exposes different options that is show to user to configure: username/password, language selection, quality, etc. Each plugin exposes different options.

In general we did not talk too much about this point, but the general feeling is that having it would be a good feature.