Re: RFC: plugin for weboob

[Bastien Nocera <hadess hadess net>]

Hey Guilhem,

On Sun, 2014-05-11 at 12:08 +0200, Guilhem Bonnefille wrote:
> Hi,
>
> I pleased to announce a project of mines, based on grilo. This project
> aims to integrate weboob into grilo based application.
> Weboob[1] is a set of application to process public web services from
> command line. Weboob mostly supports all actions of grilo: resolve,
> browse, search.

Do you have a list of sites/services that would be enabled through
Weboob? There are a number of services for which we already have
sources, and we would, in most cases, obviously prefer "native" (C or
Lua) sources to having to go through a level of indirection like Weboob.

For example, I already have a plugin for Pluzz (public French TV
catchup) that's pretty close to ready, written in Lua.

> [1] http://weboob.org/
>
> My first goal is to integrate the video part of weboob into totem. I
> did the first stage: proof of concept.
> Blog post: http://nathguil.free.fr/nikola/posts/integration-de-videoob-dans-totem-poc.html
> (french)
> Screencast: https://www.youtube.com/watch?v=S4IV_fxqye4
> Sources: https://github.com/guyou/grilo-plugins/tree/weboob

You should try it with GNOME 3.12's totem/Videos, the grilo support is
much better than in previous versions.

> My first version spawn a process and read output synchronously.
> Currently, I'm trying to revise the solution in order to add async
> processing of result. Technically, I tried two solutions for async
> processing: one based on g_input_stream read_async framework, and
> another based on a read in a g_idle task. I'm not sure what is the
> best approach. Any comment to share on this topic (I'm a big newbie on
> both grilo and async framework in glib)?

I'd recommend using GSubprocess (new in glib 2.40) to access the outputs
from the command-line tool. The subprocess handling is much more robust,
and the API more mature than what existed before in GLib.

> Please, note that another plugin idea is to integrate quvi as grilo
> plugin. While weboob try to address many topics (video, audio, bank,
> chat, etc.), quvi is focused on video. Furthermore, quvi seems to
> provide only "resolve" operation (at least in 0.4.2).

I wouldn't do that. First, a quvi plugin would leak out the AGPL
license, making it incompatible with totem's license (GPLv2 + exception
for proprietary GStreamer plugins). Furthermore, we already have support
for it in totem-pl-parser (which uses a separate process to do the
resolution, avoiding the licensing problem), which a few plugins already
use.

> Oh, I forgot: thanks for this great framework.

When your code is ready for review, please post the patches to the GNOME
Bugzilla under the grilo product. We'll iterate and review there. If
many patches are necessary, you can use git-bz to make uploading new
patches easier.

Cheers